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PREFACE 


This  document  is  the  first  of  a  series  of  planned  issuances 
comprising  the  DLA  Systems  Modernization  Methodology  (SMM), 
for  the  purpose  of  implementing  information  engineering  and  data 
management  in  the  Defense  Logistics  Agency.  These  Logical 
Analysis  and  Design  Procedures  are  to  be  used  to  create  the 
logical  level  of  DLA’s  information  architecture.  In  the  DLA 
Information  Engineering  systems  development  life  cycle,  this  step 
corresponds  to  the  business  area  analysis  (BAA)  phase. 

This  initial  version  of  these  procedures  could  not  have  been 
developed  without  the  patient  participation  of  the  Contractor 
Profile  Pilot  Team,  and  the  many  expert  consultants  who 
contributed  their  talents  to  this  effort.  These  procedures  were 
tested  and  refined  during  the  production  of  the  functional 
description  documentation  for  the  Contractor  Profile  System,  as 
the  first  prototype  for  an  information  engineering  approach  to 
modernization  in  DLA.  It  is  hoped  that  future  versions  of  SMM 
issuances  will  further  incorporate  the  experiences  and  distinctive 
needs  of  the  DLA  community,  supporting  both  the  functional  users 
and  the  systems  developers. 
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0.1  SUMMARY 


\ 


^  This  document  addresses  the  procedures  for  constructing  logical 
information  models.  These  procedures  are  part  of  the  DLA  Systems 
Modernization  Methodology  and  are  in  conformance  with  the  DLA  information 
engineering  approach.  Please  refer  to  the  documentation  of  these 
subjects  for  more  detailed  discussions  of  the  relationships  between  the 
models  which  precede  and  follow  logical  models,  why  information 
engineering  is  used,  and  why  logical  models  should  be  prepared. 

These  procedures  were  developed  and  tested  during  the  logical  analysis  of 
the  Contract  and  Contract  Administration  business  areas.  They  can  and 
are  intended  to  be  applied  to  the  analysis  of  any  functional  area. 

Figure  0-1  DLA  SYSTEM  MODERNIZATION  METHODOLOGY  MODELS  AND  ARCHITECTURES 
depicts  the  relationship  of  a  logical  model  to  the  other  models  and 
architectures  which  are  specified  in  the  DLA  information  approach.  The 
procedures  which  are  specified  in  this  document  are  for  SCOPING  between 
the  conceptual  model  and  the  logical  model,  and  for  development  of  the 
LOGICAL  FUNCTIONAL  ARCHITECTURE,  MAPS,  and  LOGICAL  DATA  ARCHITECTURE. 

The  major  steps  required  to  develop  logical  models  are:  Scoping,  Global 
Analysis,  Unit  Analysis,  Normalization,  and  Develop  User  Views.  Each 
of  these  major  steps  may  be  composed  of  substeps.  Each  step  contains 
standard  sections  as  follows:  Purpose,  Components,  Input  Products, 

General  Procedures,  Output  Products,  Rules,  Examples,  Detailed  IEW 
Procedures,  and  Detailed  PCD  Procedures. 

The  primary  automated  tools  are  IEW  (Information  Engineering  Workbench), 
and  PCD  (PC  Dictionary).  The  detailed  procedures  for  input  and 
maintenance  of  the  logical  model  in  these  tools  are  provided  in 
appendices  to  each  step's  section. 

Figure  0-2  LOGICAL  MODEL  PRODUCTS  AND  COMPONENTS  depicts  the 
relationships  between  the  products  and  components  of  the  logical  model. 
The  products  which  are  prepared  for  scoping,  the  functional  architecture, 
maps,  and  the  data  architecture  are  shown  down  the  left  side  of  the 

diagram  within  the  "products"  box.  The  components  which  are  addressed  by 

each  product  are  shown  down  the  right  side  of  the  page  in  the"components" 
box.  The  lines  between  the  products  and  components  indicate  which 
components  are  addressed  by  each  product.  A  version  of  this  diagram  is 
provided  for  each  logical  modeling  step. 

Figure  0-3  LOGICAL  MODEL  STEP  PRODUCTS  products  are  addressed  by  each  of 
the  steps  required  to  complete  the  logical  model.  The  cells  of  this 

matrix  may  contain  the  letters  C,  R,  U,  or  D.  "C"  means  that  the  product 

is  created  by  the  step.  "R"  means  that  the  product  is  read  (and 
reviewed),  "U"  means  that  it  is  updated,  and  "D"  means  that  it  may  be 
deleted.  A  version  of  this  diagram  is  provided  for  each  logical  modeling 
step. 

Figure  0-4  LOGICAL  MODEL  STEP  COMPONENTS  shows  which  components  are 
addressed  by  each  of  the  steps  required  to  complete  the  logical  model. 

The  cells  of  this  matrix  may  also  contain  the  letters  C,  R,  U,  or  D. 

A  version  of  this  diagram  is  provided  for  each  modeling  step. 
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Figure  0-5  LOGICAL  INFORMATION  ARCHITECTURE  DEVELOPMENT  PHASE  OVERVIEW 
depicts  the  relationships  between  the  various  personnel  and  components  of 
a  logical  modeling  projects  within  DLA. 

0.2  OBJECTIVES 

DLA's  approach  for  Information  Engineering  has  both  long-term  and 
short-term  objectives.  The  long-term  objectives  are: 

To  standardize  and  control  data  through  the  creation  and  maintenance 
of  Data  Architectures, 

„  To  institutionalize  the  practices  of  information  engineering 
throughout  DLA. 

To  gradually  build,  validate,  and  implement  architectures  which 
integrate  information  systems. 

•  To  promote  the  visibility  of  information  resources  as  major  assets  of 
DLA  which  require  executive  management  and  integration:  /  /• 

To  promote  and  contribute  to  DOD  or,  in  some  cases,  federal 
corporate-shared  data  bases. 

The  short-term  objectives  of  DLA's  approach  for  Information 
Engineering  are: 


To  define,  design,  and  evaluate  the  Contractor  Profile  Pilot  Study. 
That  study  will  also  help  to  validate  and  perfect  this  approach^ 

To  incorporate  and  account  for  current  DLA  Information^System 
Initiatives  (e.g.,  Immediate  Improvement  Initiative  (I,;),  Defense 
Integrated  Data  System  (DIDS),  Defense  Automatic  Addressing  System 
(DAAS)y  /  r. 


To  capitalize  on  existing  Information 
requirements  documents,  and  analyses. 
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0.3  POTENTIAL  BENEFITS 


The  application  of  information  engineering  and  of  this  approach  in  its 
completed  stage  should  result  in  the  following  benefits  to  DLA: 

Reduction  of  design  and  integration  errors,  as  well  as  disruptive 
errors  in  the  actual  construction  of  data  bases  and  the  applications 
which  use  them. 

Increased  capability  to  use  emerging  automated  construction  and 
testing  techniques,  as  well  as  acceleration  and  simplification  of  the 
systems  development  life  cycle. 

Assurance  of  the  utility,  stability,  and  integrity  of  information 
systems  through  basing  the  design  of  information  systems  explicitly  on 
DLA's  business  requirements. 

Visible  audit  trails  and  the  capability  to  assess  proposed  changes  to 
information  systems  through  the  configuration  management  of 
information  resources  using  automated  central  encyclopedias  and  data 
dictionaries. 

The  capability  to  capitalize  on  emerging  rapid  prototyping  tools 
through  structured  analysis  of  DLA's  business  and  information 
requirements. 

Integrated,  shareable  data. 

Reduction  in  requirements  for  redesign  and  reprogramming  and, 
ultimately,  systems  maintenance  through  the  portability  of  the 
Information  Engineering  products  produced  with  this  approach. 
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0.4  COMMITMENT  AND  SPONSORSHIP 


General.  The  nature  of  Information  Engineering  requires  intensive 
mid- level  management  and  user  involvement  for  up-front  development  of  the 
conceptual,  logical  and  physical  architectures  and  models  that  will 
ultimately  satisfy  the  information  requirements  of  DLA.  The  functional 
areas  comprising  the  scope  of  the  workshop  may  be  identified  by  their 
involvement  in  the  Conceptual  Modeling  Workshop  which  was  used  as  the 
foundation  for  the  Logical  Modeling  phase. 

Importance.  Gaining  commitment  and  sponsorship  prior  to  commencing 
workshop  activities  is  necessary  to  ensure  full  and  part  time  commitment 
of  appropriate  manpower  to  produce  timely  and  quality  workshop  products; 
adequate  funding  to  cover  supplies,  equipment,  and  travel  for  the 
duration  of  the  workshop;  and  responsiveness  to  questions  from  workshop 
participants  during  the  data  collection  and  validation  phases. 

Gaining  commitment.  It  is  critical  to  the  success  of  the  workshop 
that  all  levels  of  management  within  DLA  be  made  aware  of  the  benefits 
and  costs  of  information  engineering  through  briefings  and  newsletters. 
Information  briefings  may  be  developed  and  targeted  to  three  distinct 
audiences:  Upper  level  management,  which  contributes  to  the  strategic 
direction  and  provides  overall  guidance  to  the  effort;  Mid-Level 
management,  which  provides  highly  skilled  personnel  assets  to  support  the 
effort;  and  Users  who  provide  the  study  team  with  a  detailed 
understanding  of  the  day-to-day  operation  of  DLA. 

The  Executive  Sponsor.  The  Executive  Sponsor  should  be  high  enough  in 
the  organization  to  have  authority  over  all  functional  areas  within  the 
scope  of  the  study.  He  has  the  single  most  important  role  in  ensuring 
that  upper  and  mid-level  manager  understand  the  importance  of  the  project 
to  DLA.  He  should  be  provided  with  a  realistic  assessment  of  the 
benefits  and  costs  of  the  information  engineering  approach.  His 
commitment  should  be  assured  prior  to  project  start-up  activities  by 
providing  him  with  an  information  briefing  which  articulates  benefits  and 
resource  requirements  of  the  effort  as  well  as  a  detailed,  time-phased 
plan  for  completion  of  the  project.  Once  his  commitment  has  been  gained, 
it  can  be  maintained  by  monthly  or  quarterly  progress  briefings,  his 
schedule  permitting,  for  the  duration  of  the  project. 

The  Steering  Committee.  Once  Executive  Sponsorship  has  been  gained,  a 
Steering  Committee  should  be  formed  which  is  composed  of  upper-level 
management  from  all  functional  areas  within  DLA.  No  functional  area 
should  be  excluded  from  the  Steering  Committee.  Traditionally, 
commitment  of  the  Steering  Committee  increases  as  it  becomes  more  aware 
of  the  benefits  achieved  through  the  information  engineering  approach. 
They  frequently  develop  an  increased  understanding  of  the  integrated 
teamwork  normally  taken  for  granted  in  accomplishing  the  missions  of  a 
large,  complex  organization  like  DLA.  The  potential  benefits  of  sharing 
data  throughout  the  agency  with  resultant  increases  in  economy  and 
efficiency  soon  become  evident.  The  commitment  of  the  Steering  Committee 
can  be  maintained  through  frequent  In-Process  Reviews  (IPRs)  in  which 
they  play  an  active  role  in  making  decisions  concerning  the  outcome, 
scope,  methodology,  standards,  and  resources  employed  in  the  information 
engineering  approach. 
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0.5  WORKSHOP  SCOPE 


The  workshop  scope  may  be  determined  by  the  Steering  Committee  which 
takes  under  advisement  the  general  direction  given  by  the  Executive 
Sponsor  and  the  Steering  committee.  Using  the  DLA  Information 
Engineering  Approach,  the  scope  may  be  determined  by  the  functional  areas 
identified  for  study. 
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0.6  WORKSHOP  OBJECTIVES 


It  is  important  that  a  clear-cut  statement  of  the  objectives  of  the 
workshop  be  developed  in  order  to  maintain  the  focus  of  the  workshop 
participants.  In  the  case  of  the  pilot  workshop  group,  the  objectives 
are: 

To  develop  the  Information  Architecture  at  the  Logical  Level. 

To  test  a  variety  of  previously  researched  techniques  for  developing 
the  architectures. 

To  test  a  variety  of  rules,  naming  conventions,  and  standards. 

To  map  the  products  of  the  Logical  Information  Architecture  to  DLA's 
Enterprise  Model  and  functions,  the  processes  of  the  BAA,  and  to  the 
Conceptual  Information  Architecture. 
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0.7  TEAM  COMPOSITION 


The  Workshop  Leader.  The  workshop  leader  must  be  clearly  identified 
and  must  be  committed  to  the  project,  full-time  throughout  the  course  of 
the  workshop.  Because  of  the  intensity  of  the  project,  the  leader  may 
delegate  some  responsibilities  of  the  position  to  assistant  workshop 
leaders.  The  workshop  leader  provides  the  focal  point  and  resolves 
day-to-day  issues  for  the  workshop  group  on  such  matters  as  scope  and 
level  of  detail.  The  workshop  leader  identifies  requirements  for 
additional  expertise  to  augment  the  knowledge  of  the  workshop  group  and 
will  ensure  that  expertise  is  made  available.  It  is  critical  to  the 
success  of  the  project,  that  the  workshop  leader  possess  the  following 
characteristics: 

An  understanding  of  DLA's  Information  Engineering  Approach. 

An  in-depth  understanding  of  the  CFR  and  the  BAAs  and  BARS  within  the 
scope  of  the  workshop. 

An  in-depth  understanding  of  the  functional  areas  within  the  scope  of 
the  workshop. 

Credibility  with  the  functional  community  and  workshop  participants. 

Ability  to  think  at  both  the  conceptual  and  detailed  level. 

Ability  to  maintain  an  objective  perspective  and  not  be  bound  by 
organizational  (turf)  issues. 

Strong  leadership  qualities. 

The  Workshop  Facilitator.  The  role  of  the  workshop  facilitator  is  to 
provide  technical  leadership  to  the  workshop  group  in  the  development  of 
the  information  engineering  products.  The  facilitator  reinforces  the 
information  engineering  training  at  the  beginning  of  each  step  of  the 
workshop,  ensures  that  each  member  of  the  group  participates,  and 
provides  clarification  on  all  information  engineering  questions.  The 
workshop  facilitator  should  be  dedicated  full-time  to  the  workshop 
throughout  the  life  of  the  workshop.  The  workshop  facilitator  must 
possess  the  following  characteristics: 

An  in-depth  understanding  of  DLA's  Information  Engineering  Approach. 

Experience  as  a  team  member,  leader,  or  participant  in  an  information 
engineering  workshop  or  study  team. 

Experience  in  group  facilitation. 

An  understanding  of  group  dynamics. 

Strong  leadership  qualities. 

The  Version  Controller.  The  Version  Controller  keeps  the  audit  trail 
for  the  working  group.  As  each  interim  product  is  agreed  upon  by  the 
team  and  produced,  the  version  controller  ensures  that  the  correct 
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version  number  and  date  appears  on  it  and  places  it  into  the  appropriate 
version  control  file.  These  files  are  working  files  that  are  essential 
to  the  group's  progress  and  will  be  frequently  referred  to  and  provide  an 
audit  trail  when  the  final  products  are  produced.  The  Version  Controller 
must  possess  the  following  characteristics: 

An  in-depth  understanding  of  DLA's  Information  Engineering  Approach 

and  the  final  and  interim  products  of  the  workshop. 

Ability  to  work  at  a  very  detailed  level. 

Extremely  well  organized. 

The  Toolkit  Guru.  While  each  team  member  is  trained  in  the  automated 
tools  supporting  the  project,  the  toolkit  guru  assistance  when  the  tools 
do  not  appear  to  be  doing  what  they  are  supposed  to  do.  The  guru  must 
possess  the  following  characteristics: 

Intensive  training  and  experience  with  all  aspects  of  the  CASE  tool. 

Hands-on  training  and  experience  with  the  data  dictionary. 

Experience  as  an  Enable  user. 

An  understanding  of  PC-DOS. 

The  Workshop  Group.  The  workshop  group  is  the  heart  of  this  effort. 
All  of  the  leaders,  facilitators,  and  experts  can  do  nothing  without  the 
group's  functional  experience  and  expertise.  They  are  constantly 
challenged  to  provide  details  of  their  day-to-day  operations,  encapsulate 
those  details  at  the  conceptual  level,  and  break  them  down  again  to 
increasing  levels  of  detail  at  the  logical  level.  The  synergy  of  a  good 
working  group  is  the  key  to  the  success  of  a  project  of  this  nature.  The 
ideal  number  of  full-time  team  members  ranges  from  seven  to  twelve,  with 
part-time  augmentation  when  the  team  is  focused  on  a  particular  function 
or  data  supporting  that  function.  Characteristics  of  members  of  a 
workshop  group  are: 

A  broad  understanding  of  DLA. 

Expertise  in  their  functional  areas. 

Training  in  DLA's  Information  Engineering  Approach. 

Training  in  all  automated  tools  to  support  the  workshop. 

Analytical  ability. 

Ability  to  grasp  new  concepts. 

Understanding  of  reference  documents. 

Ability  to  work  effectively  in  a  group  environment. 
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Ability  to  understand  and  analyze  the  varying  levels  of  functions, 
processes,  information,  and  data  needed  by  different  activities  and 
different  management  levels. 

Good  listening  skills. 

Credibility. 

Established  Points  of  Contact  within  different  division  of  their 
functional  organizations,  both  at  headquarters  staff  and  in  the  field 
activities. 

DLA's  Architecture  Team  plays  an  important  role  in  resolving  technical 
issues  and  questions  relative  to  OLA  Information  Engineering  approach  on 
a  day-to-day  basis.  The  team  is  available  to  ensure  that  products 
produced  are  integratable  into  the  overall  conceptual  models  and  meet  the 
standards  established  by  OLA.  The  Architecture  Team  discreetly  observes 
the  workshop  sessions  and  meets  with  the  workshop  group  formally  on 
weekly  basis  to  review  their  progress  and  address  their  issues  or 
concerns. 
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0.8  EDUCATION  AND  TRAINING 


In  addition  to  detailed  training  required  by  every  workshop  participant 
and  the  Architecture  Team,  the  Executive  Sponsor  and  Principal  Staff 
Elements  should  receive  a  high-level  overview  of  the  objectives, 
methodological  approach,  resources  required  and  benefits  of  DLA's 
Information  Engineering  Approach.  Additional  information  briefings 
should  be  provided  to  organizations  supporting  the  effort  with  their 
functional  and  technical  experts. 
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0.9  PLAN  OF  ACTION 

A  detailed,  time-phased  Plan  of  Action  should  be  developed  prior  to 
workshop  startup.  If  these  procedures  are  followed  carefully,  the 
logical  level  activities  should  last  from  eight  to  ten  weeks.  The  plan 
should  include: 

The  scope  and  objectives  of  the  study  effort. 

The  organizations  participating  in  the  workshop. 

The  resources  required  for  conducting  the  workshop. 

The  methodology  steps  to  be  taken. 

The  planned  beginning  and  ending  dates  for  each  step. 

The  products  which  will  result  from  each  step. 

The  anticipated  date  the  products  will  be  completed. 

In-Process  Review  dates. 

Requirements  for  a  Final  Report. 
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0.10  LOGISTICAL  REQUIREMENTS 


The  workshop  group  requires  a  large,  well-lighted  room  with  an  adequate 
power  supply  to  accommodate  the  equipment  delineated  below.  The  workshop 
room  should  be  available  for  the  duration  of  the  study  so  that  the  team 
members  feels  it  is  their  "home"  until  the  study  is  completed. 

Automation  Support.  Listed  below  is  the  ideal  automation  support  for 
workshop  activities. 

Three  microcomputers  with  40  megabytes  of  memory. 

Two  microcomputers  should  be  equipped  with  mice  and  should  have 
KnowledgeWare1 s  Information  Engineering  Workbench  (IEW)  and  Enable 
installed. 

The  third  microcomputer  should  have  PC  Dictionary  and  Enable 
installed. 

One  Laser  Printer 

Furniture  and  Equipment.  All  furniture  and  equipment  should  be  on 
hand  and  set  up  prior  to  the  arrival  of  the  workshop  group.  Following  is 
a  suggested  list  of  furniture  and  equipment: 

Enough  tables  to  seat  two  full-time  workshop  participants  to  a 
table. 

Two  -  three  computer  tables  (depe^cng  on  the  number  of 
microcomputers. 

One  bookcase  for  reference  materials. 

Enough  comfortable  rotary  chairs  to  accommodate  all  working  group 
members  plus  four  to  six  chairs  for  observers. 

Overhead  projector  and  screen. 

One  conference  copier. 

One  PC  screen  projection  device. 

One  easel  with  butcher  paper. 

Coffee  pot  and  table. 

One  telephone  to  used  for  out-going  calls  only. 

Supplies.  Following  is  a  list  of  supplies  that  should  be  available 
for  workshop  use: 

Magic  markers  for  butcher  paper  and  conference  copier. 

Overhead  blank  transparencies. 
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Overhead  transparency  markers/pens. 

Slides  from  DLA's  Information  Engineering  training  class. 

Writing  tablets. 

Pencils  and  Pens. 

Large  three-ring  binders. 

Name  tags. 

Note  cards  (3"x5"). 

Layout  of  the  Workshop  Room.  All  equipment  should  be  set  up  and  the 
room  arranged  prior  to  the  arrival  of  the  workshop  group.  Tables  should 
be  arranged  in  a  U-Shape  in  order  for  the  working  group  to  maintain  eye 
contact  with  one  another. 
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0.11  REFERENCE  MATERIALS 

A  library  of  reference  materials  should  be  created  and  maintained  in  the 
workshop. 

DLA's  Information  Engineering  Approach  paper  (1  per  team  member). 

Any  previously  generated  conceptual  and  logical  level  products 
(1  set  per  team  member). 

Business  Area  Analyses  for  the  business  areas  being  modeled  and 
integrated  (1  set  per  team  member). 

Business  Area  Requirements  Document  (1  per  team  member). 

DLA's  Organization  and  Functions  Manual. 

DLA's  Strategic  Plan. 

Conceptual  Functional  Requirements  Document  (1  per  team  member). 

JCS  Pub  1. 

Dictionary  and  Thesaurus. 
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0.12  STARTUP  ACTIVITIES 


0.12.1  ADMINISTRATIVE  ANNOUNCEMENTS 

The  workshop  group  should  be  welcomed  by  the  workshop  leader,  who  will 
introduce  himself/herself ,  and  provide  information  concerning  badges, 
parking,  security,  location  of  nearby  restaurants  and  restrooms  and  how 
telephone  messages  will  be  disseminated  to  the  group. 

0.12.2  PROJECT  OVERVIEW 

The  Project  Manager  should  provide  the  working  group  with  an  overview 
briefing  of  the  project  and  a  brief  history  of  relevant  work  accomplished 
to  date. 


0.12.3  TEAM  BUILDING 

At  the  completion  of  the  project  overview,  the  workshop  should  be  closed 
to  all  visitors.  A  team  building  exercise  is  recommended  at  this  point. 
It  is  used  to  set  the  tone  for  the  workshop  and  acquaint  the  workshop 
participants  with  each  other. 

Introductions.  The  facilitator  provides  each  member  of  the  workshop 
group  with  a  3"x5"  card  and  asks  each  team  to  provide  their  names,  a 
description  of  their  jobs,  where  they  work,  one  thing  they  really  like 
about  themselves,  what  they  enjoy  doing  in  their  spare  time,  and  one 
thing  that  really  irritates  them.  After  the  team  members  have  filled  out 
their  cards,  each  one  discusses  the  topics  listed  on  their  card.  This 
exercise  is  usually  begun  by  the  workshop  facilitator,  who  is  likely  to 
be  the  most  comfortable  with  a  self-disclosure  exercise.  The  facilitator 
then  asks  the  person  sitting  next  to  him/her  and  the  workshop's  attention 
is  focused  on  each  team  member  in  turn.  This  simple  step  provides  the 
members  of  the  group  with  an  understanding  and  appreciation  of  the 
variety  of  personalities  in  the  workshop.  It  may  also  reduce  the 
possibility  of  one  workshop  member  inadvertently  offending  another. 

Expectations.  The  facilitator  stands  in  front  of  the  easel,  which  is 
centered  in  front  of  the  workshop  group  and  asks  them  to  list  their 
individual  expectations  of  the  workshop  one  at  a  time,  in  turn.  The 
facilitator  lists  each  expectation  on  the  butcher  paper,  until  each  of 
the  expectations  have  been  listed.  Usually,  responses  will  be  exhausted 
after  three  or  four  times  around  the  room.  The  pages  of  butcher  paper 
will  be  taped  to  the  wall.  This  exercise  is  useful  because  it  focuses 
the  working  group's  attention  to  the  work  at  hand.  The  list  of 
expectations  stays  on  the  way  until  the  workshop  has  completed  its  work. 
In  later  stages  of  the  workshop,  groups  of  this  nature  may  become  tired, 
lose  their  focus,  or  become  discouraged.  It  is  helpful  to  remind  the 
group  of  their  initial  expectations  to  regain  enthusiasm  and  momentum. 

Workshop  Rules.  It  is  important  to  establish  rules  the  group  can  work 
within.  Again,  the  workshop  group  sets  its  own  rules  that  will  apply  for 
the  duration  of  the  workshop.  The  rules  are  listed  on  butcher  paper  by 
the  facilitator  in  the  same  manner  as  expectations  were  listed. 

Initially,  the  facilitator  or  team  leader  reminds  the  team  of  the  rules, 
but  eventually  as  the  group  matures,  it  becomes  self -regulating  and  the 
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group  members  remind  each  other  when  a  rule  is  being  violated.  A  partial 
list  of  good  rules  follows: 

Everyone  participates. 

Listen  to  what  is  being  said  -  do  not  focus  on  your  rebuttal. 

Agree  to  disagree  without  rancor. 

Start  on  time. 

One  conversation  at  a  time. 

No  smoking. 

Hours  of  operation. 

Consensus  means  you  can  "live  with  the  group  decision". 

No  question  is  dumb. 

Five  minute  Rule.  If  the  discussion  begins  to  get  too 
philosophical,  the  facilitator  may  invoke  the  five  minute  rule, 
which  means  the  discussion  must  end  in  five  minutes  or  the  subject 
will  wind  up  in  the  "unresolved  issue"  list. 

0.12.4  REFERENCE  MATERIAL  REVIEW 

Each  member  of  the  working  group  is  briefed  on  all  reference  materials 
and  their  use.  Individual  copies  of  reference  materials  such  as  BAAs  and 
CFR  are  provided  to  each  team  member.  Depending  on  the  volume  of 
material  to  be  reviewed,  this  step  takes  1-1/2  to  2  days. 
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1  SCOPING 


Purpose  -  Identify  the  subset  of  the  Conceptual  Information 
Architecture  to  be  analyzed  during  the  Logical  Information 
Architecture  Development  Phase  of  a  System  Development  Project. 
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1.1  DEFINE  SCOPING  CRITERIA 


Figure  1.1-1  Step  Overview 
Figure  1.1-2  Step  Products 
Figure  1.1-3  Step  Components 


1.1.1  PURPOSE 

1.1.2  COMPONENTS 

1.1. 2.1  Objective 

1.1. 2. 2  Subject  Area 

1.1. 2. 3  Information  Requirements 

1.1.3  INPUT  PRODUCTS 

1.1. 3.1  Enterprise  Model  Objective  List 

1.1. 3. 2  Enterprise  Model  Objective  Report 

1.1. 3. 3  Enterprise  Model  Information  Requirements  List 

1.1. 3. 4  Enterprise  Model  Information  Requirements  Report 

1.1. 3. 5  References 

1.1.4  GENERAL  PROCEDURES 


1.1. 4.1  Determine  Subject  Area  Information  Requirements 

1.1. 4. 2  Determine  Subject  Area  Objective 

1.1. 4. 3  Prepare  Memo  for  Management  Approval 

1.1.5  OUTPUT  PRODUCTS 


1.1. 5.1 

1.1. 5. 2 

1.1. 5. 3 

1.1. 5. 4 


Subject  Area 
Subject  Area 
Subject  Area 
Subject  Area 


Objective  List 
Objective  Report 
Information  Requirements  List 
Information  Requirements  Report 


1.1.6  RULES 


1.1. 6.1  Subject  Area  Objective 

1.1. 6. 2  Subject  Area  Information  Requirements 


1.1.7  EXAMPLES 


Figure  1.1. 7-1 
Figure  1.1. 7-2 
Figure  1.1. 7-3 

Figure  1. 1.7-4 

Figure  1.1. 7-5 
Figure  1.1. 7-6 
Figure  1.1. 7-7 
Figure  1.1. 7-8 


Enterprise  Model  Objectives  List 
Enterprise  Model  Objectives  Report 
Enterprise  Model  Information  Requirements 
List 

Enterprise  Model  Information  Requirements 
Report 

Subject  Area  Objectives  List 

Subject  Area  Objectives  Report 

Subject  Area  Information  Requirements  List 

Subject  Area  Information  Requirements 

Report 


1.1  Appendix  A  -  Detailed  IEW  Procedures 
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1.1  Appendix  B  -  Detailed  PC  Dictionary  Procedures 


30 


PRODUCTS 


COMPONENTS 


/ 


nouw  1.1-1 


ITV  OWHMtW 


FIGURE  1.1-2 
STEP  PR00UCT3 
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RELATIONSHIPS 


1.1  DEFINE  SCOPING  CRITERIA 

1.1.1  PURPOSE 

To  ascertain  and  document  the  criteria  to  be  used  when  determining  or 
reviewing  the  scope  of  a  System  Development  Project's  Logical 
Information  Architecture  Development  Phase. 

For  a  Subject  Area  (project),  the  criteria  are  Information 
Requirements  and  an  Objective. 
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1.1.2  COMPONENTS 


1.1. 2.1  Objective 

"Something  aimed  at  or  striven  for.  Objectives  are  ends,  not  means. 
They  are  definable,  attainable  and  usually  quantifiable.  They  have  a 
mid-range  time  frame  (5  to  10  years).  Objectives  are  the  second 
highest  level  in  the  DLA  hierarchy  of  goals,  objectives,  strategies, 
and  tasks."  Extracted  from  the  DLA  1988  Strategic  Plan,  Volume  Three. 

For  a  Subject  Area  (System  Development  Project),  the  project's 
objective  identifies  the  Information  Requirements  of  strategic  value 
to  the  Enterprise. 

1.1. 2. 2  Subject  Area 

A  selected  set  of  Functions,  Processes,  Entities,  and  Relationships. 
The  selection  is  based  on  the  Subject  Area's  Information  Requirements 
and  Objective. 

1.1. 2. 3  Information  Requirements 

Information  requirements  classify  information  in  terms  of  usage  to 
meet  business  requirements.  A  Subject  Area,  at  the  highest  level  of 
the  Global  Architecture,  has  Information  Requirements.  One  of  these 
Information  Requirements  must  be  called  out  in  the  Objective  for  the 
Subject  Area.  This  single  Information  Requirement  has  strategic  value 
to  the  Enterprise.  The  other  Information  Requirements  are  supporting 
classes  of  information.  Without  these  supporting  classes,  the  data 
represented  by  the  Objective's  Information  Requirement  would  have 
little  meaning  and  thus  would  lose  its  value. 
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1.1.3  INPUT  PRODUCTS 


1.1. 3.1  Enterprise  Model  Objective  List 

1.1. 3. 2  Enterprise  Model  Objective  Report 

1.1. 3. 3  Enterprise  Model  Information  Requirements  List 

1.1. 3. 4  Enterprise  Model  Information  Requirements  Report 

1.1. 3. 5  References 

Conceptual  Functional  Requirements  (CFR)  Document 

MENS  or  Management  Requirement  Document  for  the  Subject  Area 

Any  coordinated  DLA  documentation  about  the  Subject  Area 
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1.1.4  GENERAL  PROCEDURES 


1.1. 4.1  Determine  Subject  Area  Information  Requirements 

Identify  the  Information  Requirements  for  the  Subject  Area.  These 
categories  of  information  should  identify  the  types  of  data  to  be 
contained  in  the  Subject  Area.  First  examine  the  Enterprise  Model's 
list  of  Information  Requirements  for  the  Subject  Area.  Identify  those 
that  represent  the  highest  level  of  Information  Requirement  for  the 
Subject  Area.  Examine  all  Information  Requirements  for  the  Subject 
Area  to  ascertain  any  missing  high  level  requirements.  Add  these 
Information  Requiements  to  the  Enterprise  Model. 

1.1. 4. 2  Determine  Subject  Area  Objective 

Identify  the  Enterprise's  Objective  for  the  Subject  Area.  The 
objective  must  identify  the  single  Information  Requirement  driving  the 
need  for  the  Subject  Area.  All  other  high  level  Subject  Area 
Information  Requirements  represent  supporting  information.  First 
ascertain  if  there  is  an  objective  related  to  the  Subject  Area  in  the 
Enterprise  Model . 

If  there  is  an  Objective  for  the  Subject  Area,  make  sure  it  identifies 
the  single  Information  Requirement  driving  the  need  for  the  Subject 
Area.  If  it  does  not,  the  Objective  needs  to  be  changed  to  include 
the  Information  Requirement.  Research  will  be  required  to  determine 
the  Information  Requirement  for  the  Objective.  The  research  will 
examine  documents  like  the  CFR  or  any  other  coordinated  document  that 
identifies  management's  direction  for  the  project. 

If  there  is  not  an  Objective  for  the  Subject  Area,  define  one. 

Research  will  be  required  to  determine  the  Information  Requirement, 
see  the  above  paragraph.  Add  the  new  Objective  to  the  Enterprise 
Model . 

1.1. 4. 3  Prepare  Memo  for  Management  Approval 

A  formal  IOM  is  required  to  document  and  distribute  the  project  team's 
recommendation  of  scoping  criteria  for  review  and  approval.  It  is 
management's  perogative  to  review  and  critique  the  Subject  Area's 
Objective  and  Information  Requirements  to  assure  the  eventual  system 
properly  reflect  management's  requirements.  The  memorandum  also 
formally  sets  the  proper  expectation  for  what  the  system  will  provide. 
The  project  team  is  expected  to  base  the  scope  of  the  system  on  the 
scoping  criteria  (Objective  and  Information  Requirements)  documented 
in  the  memorandum.  The  risk  is  management  may  want  changes.  If  so, 
rework  may  be  required.  To  minimize  this  risk,  a  deadline  should  be 
set  for  management's  approval. 
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1.1.5  OUTPUT  PRODUCTS 

1.1. 5.1  Subject  Area  Objective  List 

1.1. 5. 2  Subject  Area  Objective  Report 

1.1. 5. 3  Subject  Area  Information  Requirements  List 

1.1. 5. 4  Subject  Area  Information  Requirements  Report 
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1.1.6  RULES 


1.1. 6.1  Subject  Area  Objective 

A  Subject  Area  must  have  an  Objective  that  states  the  single 
Information  Requirement  that  is  driving  the  Enterprise's  need  for  the 
Subject  Area. 

1.1. 6. 2  Subject  Area  Information  Requirements 

At  the  highest  level,  a  Subject  Area  may  have  several  Information 
Requirements. 
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1.1.7  EXAMPLES 


Figure 

1, 

.1 

.7 

1 

Figure 

1, 

.1 
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2 

F igure 

1, 

.  1 . 

.7 

3 

Figure 

1, 

.1 

.7 

4 

Figure 

1, 

.1. 

.7 

5 

Figure 

1, 

.1 

.7 

6 

Figure 

1, 

.1 

.7 

7 

Figure 

1, 

.1 

.7 

8 

Enterprise  Model  Objectives  List 

Enterprise  Model  Objectives  Report 

Enterprise  Model  Information  Requirements  List 

Enterprise  Model  Information  Requirements  Report 

Subject  Area  Objectives  List 

Subject  Area  Objectives  Report 

Subject  Area  Information  Requirements  List 

Subject  Area  Information  Requirements  Report 
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07/02/90 
Member  Type 

OBJECTIVE 


32  Member(s)  Defined 


F igure  1.1.7- 


DEFENSE  LOGISTICS  AGENCY 
List  Query 
Member  Name 

OB - PROV-CNTRC - PRFMC - DATA 
OBJ-OOOOl -OBTN-SFCNT-ESN-MTL 
OBJ-00002-IMPRV-KNLDG-CUST-RQ 
OBJ-00003-ACHV-WPN-SYS-SPT-CAPBL 
OBJ-00004-CUST-RQ-LOW-COST 
OB J- 0  0006 -MAX-REUTL-TRFR-PRPTY 
OBJ-00007-PRCLD-SNSTV-ITEM 
OBJ-OOOO8-ACHV-MODRN-SYS-PRCDR 
OBJ-OOOOS-ACHV-RQ-LEVEL-PRTCP 
OBJ-OOO 10-ACHV-SYS-PRCDR-SPT-RQ 
OB J- 0  0  0 1 1 - IMPRV-TRNSP-MGT 
OBJ-OOO 1 2-REDC-IMPRV-DISTR-SYS 
OBJ-OOO 1 3- OPTMZ-COST-MINM-TRFR 
OB J- 0  0014 -ACHV-HI -EMPL-MOTVN 
OBJ -00015- IMPRV-PRSNL-MGT- AUTO 
OB J- 0  0016 -ACHV-PRSNL-MGT- EXPAN 
OBJ-0001 7 -MAX-OPG-INFO-MGT-RESRC 
OB J- 0  0018 -MAX-DATA- INTEG-SHR 
OB J-0  0 019 -REDC-ACQR-DEVLP-SYS-TM 
OBJ-00020-ACHV-UNDRS-COST-BNFIT 
OBJ-OOO 2 1-EXPAN-ELEC-INTCG-INTEG 
OBJ-OOO 22-MAX-EFCNT-INFO-OPRN 
OB J- 0  0023 -ACHV-CLR-ORG-MGMT-SYS 
OBJ-OOO 24 -ACHV-DVLP-REFN-PROCS 
OBJ-OOO 25-ACHV-OPTM-STRUC 
OBJ-OOO 26 -ACHV-RESRC-PROVD-SPT 
OBJ-OOO 27 -ALCTN-RESRC 
OB J- 0  00  28 -ACHV-VI SBL-RESRC 
OB J- 0 0 0 2 9 - ACHV- Z ERO-LAG-TM 
OBJ-00030-ACHV-MINM-FACIL-COST 
OBJ-OOO 3 1-ACHV-EFCNT-FACIL-UTIL 
OBJ-OOO 3 2-ACHV-OPTM-TECH-OPRN 


1  Enterprise  Model  Objectives  List 
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07/02/90 
Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 


Page  1 


Attribute  Name  &  Contents 


OBJECTIVE 

08J-00001-0BTN-SFCNT-ESN-MTL  CATALOGUE 

DEFINITION 

Obtain  sufficient  essential  materiel  to  meet  readiness  and  sustainability 
requirements  for  the  full  spectrum  of  operating  scenarios, 

ENTRY-CONTENT -APPROVER-ORG 
FULL-NAME 

Obtain  Sufficient  Essential  Materiel 
SOURCE 

DLA  1988  Strategic  Plan,  page  32 


Figure  1.1. 7-2  Enterprise  Model  Objectives  Report 
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07/02/90 
Member  Type 

INFORMATION-REQUIREMENT 


DEFENSE  LOGISTICS  AGENCY 
List  Query 
Member  Name 

IR-0001 

IR-0002 

IR-0003 

IR-0004 

IR-0005 

IR-0006 

IR-0007 

IR-0008 

IR-0009 

IR-0010 

IR-0011 

IR-0012 

IR-0013 

IR-0014 

IR-0015 

IR-0016 

IR-0017 

IR-0018 

IR-0019 

IR-0020 

IR-0021 

IR-0022 

IR-0023 

IR-0024 

IR-0025 

IR-0026 

IR-0027 

IR-0028 

IR-0029 

IR-0030 

IR-0031 

IR-0032 

IR-0033 

IR-0034 

IR-0035 

IR-0036 

IR-0037 

IR-0038 

IR-0039 

IR-0040 

IR-0041 

IR-0042 

IR-0043 

IR-0044 

IR-0045 

IR-0046 

IR-C047 

IR-0048 

IR-0049 

IR-BID-PROPL 

IR-CNTRC-CBLTY 
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07/02/90 
Member  Type 


56  Member(s) 


DEFENSE  LOGISTICS  AGENCY 
List  Query 
Member  Name 


IR-CNTRC-CHARC 

IR-CNTRC-CONTR-PRFMC 

IR-CONTR-REQMT 

IR-GOVT-PRFMC 

IR-ITEM 


Defined 


Figure  1. 1.7-3  Enterprise 


Model  Information  Requirements  L 


07/02/90 
Member  Type 
Member  Name 


INFORMATION 

IR-0001 


OEFENSE  LOGISTICS  AGENCY 

Member  Definition  Report  Page  1 

Attribute  Name  &  Contents 


■REQUIREMENT 

CATALOGUE 

CONTRACTOR  PROFILE 
DEFINITION 

Contractors  should  track  subcontractors  performance. 
ENTRY-CONTENT -APPROVER-ORG 
FULL-NAME 
SOURCE 
CONTAINS 


Figure  1 . 1 . 7-4  Enterprise  Model  Information  Requirements  Report 
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07/02/90 


DEFENSE  LOGISTICS  AGENCY 
Catalogue  Query 

The  following  members  satisfy  this  condition 
OBJECTIVE  AND  CONTRACTOR  PROFILE. 

Member  Name  Member  Type 


OB-PROV-CNTRC-PRFMC-DATA  OBJECTIVE 


1  Member(s)  Satisfying  Catalogue  Query 


Figure  1 . 1 . 7-5 


Subject  Area  Objectives  List 
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07/02/90 
Member  Type 
Member  Name 


OBJECTIVE 

0B-PR0V-CNTRC 


DEFENSE  LOGISTICS  AGENCY 

Member  Definition  Report  Page  1 

Attribute  Name  &  Contents 


PRFMC-DATA  CATALOGUE 

CONTRACTOR  PROFILE 
OBJECTIVE 
DEFINITION 

Provide  contractor  performance  data  in  order  to  award  contracts  to  the 
best  performing  contractors. 

ENTRY-CONTENT-APPROVER-ORG 

FULL-NAME 

Provide  Contractor  Performance  Data 
SOURCE 

Team  member  knowledge 


Figure  1.1. 7-6 


Subject  Area  Objectives  Report 
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07/02/90 


DEFENSE  LOGISTICS  AGENCY 
Catalogue  Query 

The  following  members  satisfy  this  condition... 
INFORMATION  REQUIREMENT  AND  CONTRACTOR  PROFILE. 

Member  Name  Member  Type 

IR-CNTRC-CBLTY  INFORMATION-REQUIREMENT 

IR-CNTRC-CHARC  INFORMATION-REQUIREMENT 

IR-CNTRC-CONTR-PRFMC  INFORMATION-REQUIREMENT 

3  Member(s)  Satisfying  Catalogue  Query 


Figure  1 . 1 . 7-7  Subject  Area  Information  Requirements  List 
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07/02/90 
Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 


Page  1 


Attribute  Name  &  Contents 


INFORMATION-REQUIREMENT 

IR-CNTRC-CBLTY  CATALOGUE 

CONTRACTOR  PROFILE 
INFORMATION  REQUIREMENT 
DEFINITION 

Information  which  identifies  and  describes  a  contractor's  ability  and 
capacity  to  provide  a  service  or  a  product. 

ENTRY-CONTENT-APPROVER-ORG 

FULL-NAME 

Contractor  Capability 
SOURCE 

Team  member  knowledge 
CONTAINS 
EN-ITEM 

EN-LEGAL-ENTY 

EN-OFFER 

IR-0001 

IR-0002 

IR -0010 

IR-0016 

IR-0021 

IR-0022 

IR-0024 

IR-0041 

IR-0045 

IR-0049 


INFORMATION-REQUIREMENT 

IR-CNTRC-CHARC  CATALOGUE 

CONTRACTOR  PROFILE 
INFORMATION  REQUIREMENT 
DEFINITION 

Information  which  identifies  and  describes  a  given  contractor's  resources 
and  their  locations. 

ENTRY-CONTENT-APPROVER-ORG 

FULL-NAME 

Contractor  Characteristics 
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07/02/90 
Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 


Page 


Attribute  Name  &  Contents 
SOURCE 

Team  member  knowledge 
CONTAINS 
EN-ITEM 

EN-LEGAL-ENTY 

EN-OFFER 

IR-0021 

IR-0022 


Figure  1 . 1 . 7-8  Subject  Area  Information  Requirements  Report 


1.1  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 

1.1  DEFINE  SCOPING  CRITERIA 

There  are  no  IEW  procedures  for  this  section. 
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1.1  APPENDIX  8  -  DETAILED  PC  DICTIONARY  PROCEDURES 

1.1  DEFINE  SCOPING  CRITERIA 

Reference  Appendix  D,  GENERAL  PC  DICTIONARY  PROCEDURES,  for  more 
details  on  how  to  ADD,  EDIT,  DELETE,  COPY,  RENAME,  REPORT,  or  QUERY 
dictionary  members. 

1.1.1  PURPOSE 

The  purpose  in  these  PC  DICTIONARY  detailed  procedures  is  to  explain 
how  to  capture  and  report  the  information  that  is  gathered  while 
defining  the  scoping  criteria. 

1.1.2  COMPONENTS/TERMS 

1.1.3  INPUT  PRODUCTS 

1.1. 3.1  Enterprise  Model  Objectives  List 
(Get  report  of  Objectives) 

1.1. 3. 1.1  Select  MEMBER  DEFINITION  from  REPORT  MENU. 

1.1. 3. 1.2  Select  all  members  that  begin  with  the  objective  member  type 
prefix. 

1.1. 3. 1.3  Check  report  destination  [ALT-F10]. 

1.1. 3. 1.4  Start  report  [F10] . 

1.1. 3. 2  Enterprise  Model  Information  Requirements  List 
(Get  report  of  Information  Requirements) 

1.1. 3. 1.1  Select  MEMBER  DEFINITION  from  REPORT  MENU. 

1.1. 3. 1.2  Select  all  members  that  begin  with  the  information 
requirement  prefix. 

1.1. 3. 1.3  Check  report  destination  [ALT-F10] . 

1.1. 3. 1.4  Start  report  [F10]. 

1.1.4  GENERAL  PROCEDURES 

1.1. 4.1  Determine  Subject  Area  Information  Requirements 

(If  the  needed  Information  Requirement(s)  already  exists,  then...) 

1.1. 4. 1.1  Edit  each  Information  Requirement  that  has  been  selected  for 
the  Subject  Area. 

1.1. 4. 1.2  Edit  the  'CATALOG'  attribute. 

1.1. 4. 1.3  Add  the  CATALOG  'CONTRACTOR  PROFILE'. 
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1.1. 4. 1.4  Add  another  CATALOG  'INFORMATION  REQUIREMENT'. 

1.1. 4. 1.5  Save  CATALOGS. 

1.1. 4. 1.6  Edit  any  other  attributes,  as  needed. 

1.1. 4. 1.7  Save  the  Information  Requirement. 

(If  the  Information  Requirement  is  new,  then...) 

1.1. 4. 1.8  Add  each  new  Information  Requirement  that  has  been  selected 
for  the  Subject  Area. 

1.1. 4. 1.9  Edit  the  CATALOG  attribute. 

1.1.4.1.10  Add  the  CATALOG  'CONTRACTOR  PROFILE'. 

1.1.4.1.11  Add  another  CATALOG  'INFORMATION  REQUIREMENT'. 

1.1.4.1.12  Save  CATALOGS. 

1.1.4.1.13  Edit  any  other  attributes,  as  needed. 

1.1.4.1.14  Save  Information  Requirement. 

1.1. 4. 2  Determine  Subject  Area  Objective 
(If  an  Objective  already  exists,  then...) 

1.1. 4. 2.1  Edit  each  Objective  that  has  been  selected  for  the  Subject 
Area. 

1.1. 4. 2. 2  Edit  the  CATALOG  attribute. 

1.1. 4. 2. 3  Add  the  CATALOG  'CONTRACTOR  PROFILE1. 

1.1. 4. 2. 4  Add  another  CATALOG  'OBJECTIVE',  if  not  already  added. 

1.1. 4. 2. 5  Save  CATALOGS. 

1.1. 4. 2. 6  Edit  any  other  attributes,  as  needed. 

1.1. 4. 2. 7  Save  Objective. 

(If  the  Objective  is  new,  then...) 

1.1. 4. 2. 8  Add  the  new  Objective  that  has  been  selected  for  the  Subject 
Area. 

1.1. 4. 2. 9  Edit  the  CATALOG  attribute. 

1.1.4.2.10  Add  the  CATALOG  'CONTRACTOR  PROFILE'. 

1.1.4.2.11  Add  another  CATALOG  'OBJECTIVE'. 

1.1.4.2.12  Save  CATALOGS. 

1.1.4.2.13  Edit  DEFINITION. 
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1.1.4.2.14 


Provide  meaningful  definitions  for  the  objective. 

1.1.4.2.15  Save  DEFINITION. 

1.1.4.2.16  Edit  any  other  attributes,  as  needed. 

1.1.4.2.17  Save  Objective. 

1.1.5  OUTPUT  PRODUCTS 

1.1. 5.1  Subject  Area  Objective  Reports 

(Get  list  of  Objective  that  was  identified  for  the  Subject  Area) 

1.1. 5. 1.1  Select  CATALOGUE  from  QUERY  MENU. 

1.1. 5. 1.2  Select  query  logic,  EQUAL. 

1.1. 5. 1.3  Enter  catalogue  name,  CONTRACTOR  PROFILE,  or  select  from 
look  up  list  [F2] . 

1.1. 5. 1.4  Select  query  logic,  EQUAL. 

1.1. 5. 1.5  Enter  catalogue  name,  OBJECTIVE,  or  select  from  look  up  list 
[F2]. 

1.1. 5. 1.6  Check  report  destination  [ALT-F10]. 

1.1. 5. 1.7  Start  query  [F10] . 

(Get  report  of  Objective) 

1.1. 5. 1.8  Select  MEMBER  DEFINITION  from  REPORT  MENU. 

1.1. 5. 1.9  Select  all  member(s)  that  were  on  the  previous  Catalog  Query 
list. 

1.1.5.1.10  Check  report  destination  [ALT-F10]. 

1.1.5.1.11  Start  report  [F10]. 

1.1. 5. 2  Subject  Area  Information  Requirements  Reports 

(Get  list  of  Information  Requirements  that  were  identified  for  the 

Subject  Area) 

1.1. 5. 2.1  Select  CATALOGUE  from  QUERY  MENU. 

1.1. 5. 2. 2  Select  query  logic,  EQUAL. 

1.1. 5. 2. 3  Enter  catalogue  name,  CONTRACTOR  PROFILE,  or  select  from 
look  up  list  [F2] . 

1.1. 5. 2. 4  Select  query  logic,  EQUAL. 

1.1. 5. 2. 5  Enter  catalogue  name,  INFORMATION  REQUIREMENT,  or  select 
from  look  up  list  [F2] . 
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1.1. 5. 2. 6  Check  report  destination  [ALT-F10]. 

1.1. 5. 2. 7  Start  query  [F10]. 

(Get  report  of  Information  Requirements) 

1.1. 5. 2. 8  Select  MEMBER  DEFINITION  from  REPORT  MENU. 

1.1. 5. 2. 9  Select  all  member(s)  that  were  on  the  previous  Catalog  Query 
list. 

1.1.5.2.10  Check  report  destination  [ALT-F10]. 

1.1.5.2.11  Start  report  [F10]. 


1.2  SELECT  CONCEPTUAL  ENTITIES 

Figure  1.2-1  Step  Overview 
Figure  1.2-2  Step  Products 
Figure  1.2-3  Step  Components 

1.2.1  PURPOSE 

1.2.2. 1  Entity  Type 

1.2. 2. 2  Entity 

1.2. 2. 3  Conceptual  Entity  Type 

1.2. 2. 4  Information  Requirement 

1.2.3  INPUT  PRODUCTS 

1.2. 3.1  CDA  Entity  Relationship  Diagram  (ERD) 

1.2. 3. 2  CDA  Entity  Type  List 

1.2. 3. 3  CDA  Entity  Type  Report 

1.2. 3. 4  Subject  Area  Information  Requirements  Report 

1.2.4  GENERAL  PROCEDURES 

1.2. 4.1  Review  CDA  Entities 

1.2. 4. 2  Identify  Subject  Area  Entity  Types 

1.2.5  OUTPUT  PRODUCTS 


1.2. 5.1 

1.2. 5. 2 

1.2. 5. 3 

1.2.6  RULES 


Subject  Area  ERDS 

Subject  Area  Entity  Type  List 

Subject  Area  Entity  Type  Report 


1.2. 6.1  Adherence  to  scoping  criteria 
1.2.7  EXAMPLES 


Figure  1.2. 7-1 
Figure  1.2. 7-2 
Figure  1.2. 7-3 
Figure  1.2. 7-4 

Figure  1.2. 7-5 
Figure  1.2. 7-6 
Figure  1.2. 7-7 


CDA  Entity  Relationship  Diagram  (ERD) 

CDA  Entity  Type  List 

CDA  Entity  Type  Report 

Subject  Area  Information  Requirements 

Report 

Subject  Area  ERDS 

Subject  Area  Entity  Type  List 

Subject  Area  Entity  Type  Report 


1.2  Appendix  A  -  Detailed  I EW  Procedures 

1.2  Appendix  B  -  Detailed  PC  Dictionary  Procedures 
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DATA 

ARCHITECTURE 


X.  PRODUCTS 

1.2SX 

SELECT 

CONCEPTUAL  \ 
ENTITIES  \ 
STEPS 


FIGURE  1J-2 

1 

1 

STEP  PRODUCTS 

1 
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1 

1 

ENTITY  RELATIONSHIP  DIAGRAM 
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SCREEN  FUNCTIONS*  COMMANOS 


1.2  SELECT  CONCEPTUAL  ENTITIES 


1.2.1  PURPOSE 

The  purpose  of  this  one-time  step  is  to  choose  the  entity  types  from 
the  Conceptual  Data  Architecture  (CDA)  that  pertain  to  the  Subject  Area 
being  analyzed,  providing  a  starting  point  for  further  analysis.  In  a 
later  step,  these  selected  entity  types  will  be  fully  attributed  and 
all  relationships  between  the  selected  entity  types  will  be  identified. 
Relationships  from  the  selected  (in-scope)  entity  types  to  the 
non-selected  (out-of-scope)  entity  types  will  also  be  identified  to 
show  the  connection  to  other  subject  areas. 
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1.2.2  COMPONENT/TERMS 
1.2. 2.1  Entity  Type 


The  collection  of  all  the  entities  to  which  a  specific  definition, 
common  attributes  and  relationships  apply. 

1.2. 2. 2  Entity 

An  Entity  is  a  person,  place,  thing,  concept,  or  event  about  which  the 
Enterprise  requires  information.  It  is  also  called  entity  instance  or 
entity  occurrence. 

1.2. 2. 3  Conceptual  Entity  Type 

Any  entity  type  contained  in  the  Conceptual  Data  Architecture  (CDA). 
They  each  represent  fundamental  and  broad  classifications  of  Entities. 

1.2. 2. 4  Information  Requirement 
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1.2.3  INPUT  PRODUCTS 

1.2. 3.1  CDA  Entity  Relationship  Diagram  (ERD)  (Figure  1.2. 7-1) 

This  diagram  contains  all  the  entity  types  that  were  identified  in  the 
CDA. 

1.2. 3. 2  CDA  Entity  Type  List  (Figure  1.2. 7-2) 

This  list  will  contain  the  entity  types  from  the  CDA. 

1.2. 3. 3  CDA  Entity  Type  Report  (Figure  1.2. 7-3) 

This  report  describes  the  entity  types  from  the  CDA. 

1.2. 3. 4  Subject  Area  Information  Requirements  Report  (Figure  1.2. 7-4) 

This  report  will  define  the  Subject  Area  Information  Requirements  as 
identified  in  1.1  Define  Scoping  Criteria. 
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1.2.4  GENERAL  PROCEDURES 


1.2. 4.1  Review  CDA  Entities 

Study  the  definitions  of  all  of  the  conceptual  entity  types.  While 
viewing  the  ERD,  understand  that  the  relationships  between  the 
Conceptual  entity  types  are  place  holders  for  further  development. 

1.2. 4. 2  Identify  Subject  Area  Entity  Types 

Compare  the  definitions  of  the  Conceptual  entity  types  with  the  Subject 
Area  Information  Requirements  to  determine  which  entity  types  from  the 
CDA  are  needed  to  satisfy  the  Information  Requirements.  Edit  entity 
type  definitions  as  needed.  Document  which  entity  types  are  within  the 
Subject  Area.  This  is  done  through  the  cataloging  feature  of  the 
dictionary. 

1.2. 4. 3  Review  Subject  Area  Entity  Types 

Review  Subject  Area  entity  type  definitions  for  completeness  and 
accuracy  while  making  sure  these  Entity  types  pertain  to  the  Subject 
Area.  Modify  the  Entity  types  and/or  the  diagram,  as  needed. 
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1.2.5  OUTPUT  PRODUCTS 

1.2. 5.1  Subject  Area  ERDs  (Figure  1.2. 7-5) 

Each  of  these  ERDS  will  only  show  one  entity  type  that  is  within  scope 
with  its  existing  relationships  to  other  Entity  types. 

1.2. 5. 2  Subject  Area  Entity  Type  List  (Figure  1.2. 7-6) 

This  list  will  contain  the  entity  types  that  have  been  selected  for  the 
Subject  Area  being  analyzed. 

1.2. 5. 3  Subject  Area  Entity  Type  Report  (Figure  1.2. 7-7) 

This  report  describes  the  entity  types  that  have  been  selected  for  the 
Subject  Area  being  analyzed. 
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1.2.6  RULES 

1.2.6. 1  Adherence  to  scoping  criteria 

All  chosen  entity  types  must  pertain  to  the  Information  Requirements 
identified  in  1.1  Define  Scoping  Criteria. 
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1.2.7  EXAMPLES 


Figure  1.2. 7-1  CDA  Entity  Relationship  Diagram  (ERD) 

Figure  1.2. 7-2  CDA  Entity  Type  List 
Figure  1.2. 7-3  CDA  Entity  Type  Report 

Figure  1.2. 7-4  Subject  Area  Information  Requirements  Report 

Figure  1.2. 7-5  Subject  Area  ERDS 

Figure  1.2. 7-6  Subject  Area  Entity  Type  List 

Figure  1.2. 7-7  Subject  Area  Entity  Type  Report 


S  ()  N 


Figure  1.2. 7-1  ('DA  Entity  Relationship  Diagram 


07/02/90 


DEFENSE  I OGISTICS  AGENCY 
Catalogue  Query 

The  following  members  satisfy  this  condition 

CONCEPTUAL. 


Member  Name 

Member  Type 

EN-CONTR 

ENTITY 

EN-CUST 

ENTITY 

EN-EMPL 

ENTITY 

EN-FUND-ACCT 

ENTITY 

EN-ITEM 

ENTITY 

EN-LENTY 

ENTITY 

EN-OFFER 

ENTITY 

EN-ORG 

ENTITY 

EN-PR 

ENTITY 

EN-SOLCN 

ENTITY 

10  Member(s)  Satisfying  Catalogue  Query 


Figure  1.2. 7-2  CDA  Entity  Type  List 
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07/02/90 
Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 


Page  1 


Attribute  Name  &  Contents 


ENTITY 

EN-CONTR  ALIAS 

CATALOGUE 
CONCEPTUAL 
CONTRACTOR  PROFILE 
ENTITY 
SUBSTANTIVE 
DEFINITION 

A  contract  is  a  mutually  binding  legal  instrument  obligating  the  seller 
to  furnish  the  supply,  service,  or  data  items  and  the  buyer  to  pay  for 
them. 

DESCRIPTION 

In  addition  to  bilateral  instruments,  contracts  include  (but  are  not 
limited  to)  job  orders  or  task  letters  issued  under  basic  order 
agreements;  letter  contracts;  orders,  such  as  purchase  orders,  under 
which  the  contract  becomes  effective  by  written  acceptance  or 
performance. 

ENTRY-CONTENT-APPROVER-ORG 

ENTRY-CONTENT-MAINTAINER-ORG 

FULL-NAME 

Contract 

SOURCE 

Team  member  knowledge 
FAR  subpart  2.1 
IDENTIFIER  IS 
CT-CONTR-NBR 
MULTI -ASSOCIATION  TO 
MULTI -ATTRIBUTES  ARE 
ONE-ASSOCIATION  TO 
ONE -ATTRIBUTES  ARE 
CT-C0NTR-CL0SD-0ATE 

CT-CONTR-DOLR-AMT 

CT-CONTR-EFCTV -AWARD-DATE 

CT-CONTR-PAYMT-TERM-TEXT 

CT-CONTR-DPAS-RATE-CD 

CT-CONTR-STAT-INDCT 

CT-CONTR  -0BGD-D0LR  -AMT 
SEE 

SUB-ENTITIES  ARE 
EN-CONTR -MOD 

EN-CLAUS 

EN-SOW-ELMNT 
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07/02/90 
Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 

Attribute  Name  &  Contents 


Page 


EN-LNITM 


Figure  1.2. 7-3  CDA  Entity  Tvpe  Report 
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07/02/90 
Member  Type 
Member  Name 


INFORMATION-REQUIREMENT 

IR-CNTRC-CHARC 


INFORMATIOf  REQUIREMENT 
IR-CNTRC-C0nTR-PRFMC 


DEFENSE  LOGISTICS  AGENCY 

Member  Definition  Report  Page  1 

Attribute  Name  &  Contents 


CATALOGUE 

CONTRACTOR  PROFILE 
INFORMATION  REQUIREMENT 
DEFINITION 

Information  which  identifies  and  describes  a  given  contractor's  resources 
and  their  locations. 

ENTRY-CONTENT-APPROVER-ORG 

FULL-NAME 

Contractor  Characteristics 
SOURCE 

Team  member  knowledge 
CONTAINS 
EN-ITEM 

EN-LEGAL-ENTY 

EN-OFFER 

IR-0021 

IR-0022 


CATALOGUE 

CONTRACTOR  PROFILE 
INFORMATION  REQUIREMENT 
DEFINITION 

Information  which  indicates  a  given  contractor's  effectiveness  and 
efficiency  to  satisfy  contractual  obligations.  This  information 
indicates  performance  on  items,  performance  on  an  individual  contract, 
aggregate  performance  on  multiple  contracts,  or  performance  with  other 
Government  customers  and/or  non-Government  clients. 
ENTRY-CONTENT-APPROVER-ORG 
FULL-NAME 

Contractor  or  Contract  Performance 
SOURCE 

Team  member  knowledge 
CONTAINS 
EN-CONTR 

EN-ITEM 

EN-LEGAL-ENTY 

IR-0001 

IR-0002 
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07/02/90 
Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 

Member  Definition  Report  Page  2 

Attribute  Name  &  Contents 
IR-0004 
IR-0010 
IR-0016 
IR-0017 
IR-0021 
IR-0022 
IR-0038 
IR-0040 
IR-0041 
IR-0045 
IR-0048 


Figure  1.2. 7-4  Subject  Area  Information  Requirements  Report 


72 


7 


Figure  1.3. 7-5  Subject  Area  Entity  Relationship  Diagram 


07/02/90 


DEFENSE  LOGISTICS  AGENCY 
Catalogue  Query 

The  following  members  satisfy  this  condition... 
ENTITY  AND  CONTRACTOR  PROFILE. 


Member  Name 

Member  Type 

EN -ALERT -ACTN 

ENTITY 

EN-ALERT-ACTN-RSN-TYPE 

ENTITY 

EN-ALERT-ACTN-TYPE 

ENTITY 

EN-CAR 

ENTITY 

EN-CLAUS 

ENTITY 

EN-CLAUS-TYPE 

ENTITY 

EN-CONTR 

ENTITY 

EN-CONTR-MOD 

ENTITY 

EN-CONTR-QL 

ENTITY 

EN-CONTR-TYPE 

ENTITY 

EN-CUST 

ENTITY 

EN-DEFCN 

ENTITY 

EN-DEFCN-INVST 

ENTITY 

EN-DEFCN- INVST-TYPE 

ENTITY 

EN-DID 

ENTITY 

EN-DISCL 

ENTITY 

EN-ECP 

ENTITY 

EN-EMPL 

ENTITY 

EN-EMPL-CONTR-ROLE 

ENTITY 

EN-EMPL-CONTR-ROLE-TYPE 

ENTITY 

EN-FAT-RSLT 

ENTITY 

EN-FUND-ACCT 

ENTITY 

EN-GOVAG 

ENTITY 

EN-GOVAG-CONTR-ROLE 

ENTITY 
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07/02/90 
Member  Name 

EN-GOVAG-CONTR-ROLE-TYPE 

EN-ITEM 

EN-ITEM-FSC 

EN-LAB-TEST 

EN-LENTY 

EN-LENTY-CBLTY 

EN-LENTY-POP 

EN-LENTY-SRV 

EN-LENTY-SRV-TYPE 

EN-LNITM 

EN-LNITM-INVST 

EN-LNITM-SRVLC 

EN-OFFER 

EN-PAS-RCMDN 

EN-PKGNG-CBLTY 

EN-PR 

EN-PRFMC 

EN-PRFMC-FNAR 

EN-PRFMC-RCGTN 

EN-PROD-DLVAC 

EN-PROD- INSPC 

EN-PROD-INSPC-TYPE 

EN-PRODC-CBLTY 

EN-QA-CBLTY 

EN-SFTY-CBLTY 

EN-SOLCN 


DEFENSE  LOGISTICS  AGENCY 
Catalogue  Query- 
Member  Type 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 

ENTITY 
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07/02/90 
Member  Name 

EN-SOW-ELMNT 

EN-TECH-CBLTY 

EN-TRNSP-CBLTY 

EN-WAIVR-DEVTN 

54  Member (s) 


DEFENSE  LOGISTICS  AGENCY 
Catalogue  Query 
Member  Type 

ENTITY 

ENTITY 

ENTITY 

ENTITY 


Satisfying  Catalogue  Query 


Figure  1.2. 7-6  Subject  Area  Entity  Type  Lis 
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07/02/90 
Member  Type 
Member  Name 


ENTITY 

EN-CONTR 


DEFENSE  LOGISTICS  AGENCY 

Member  Definition  Report  Page  1 

Attribute  Name  &  Contents 


ALIAS 
CATALOGUE 
CONCEPTUAL 
CONTRACTOR  PROFILE 
ENTITY 
SUBSTANTIVE 
DEFINITION 

A  contract  is  a  mutually  binding  legal  instrument  obligating  the  seller 
to  furnish  the  supply,  service,  or  data  items  and  the  buyer  to  pay  for 
them. 

DESCRIPTION 

In  addition  to  bilateral  instruments,  contracts  include  (but  are  not 
limited  to)  job  orders  or  task  letters  issued  under  basic  order 
agreements;  letter  contracts;  orders,  such  as  purchase  orders,  under 
which  the  contract  becomes  effective  by  written  acceptance  or 
performance. 

ENTRY-CONTENT-APPROVER-ORG 
ENTRY-CONTENT-MAINTAINER-ORG 
FULL -NAME 
Contract 
SOURCE 

Team  member  knowledge 
FAR  subpart  2.1 
IDENTIFIER  IS 
CT-CONTR-NBR 
MULTI-ASSOCIATION  TO 
MULTI -ATTRIBUTES  ARE 
ONE -ASSOCIATION  TO 
ONE-ATTRIBUTES  ARE 
CT -CONTR-CLOSD-DATE 

CT-CONTR-OOLR-AMT 

CT-CONTR -EFCTV-AWARD-DATE 

CT-CONTR-PAYMT-TERM-TEXT 

CT-CONTR-DPAS-RATE-CD 

CT-CONTR -STAT- I NDCT 

CT-CONTR -OBGD-DOLR -AMT 
SEE 

SUB-ENTITIES  ARE 
EN-CONTR-MOD 

EN-CLAUS 

EN-SOW-ELMNT 

Figure  1.2. 7-7  Subject  Area  Entity  Type  Report 
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1.2  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 


1.2  SELECT  CONCEPTUAL  ENTITIES 

1.2.1  PURPOSE 

1.2.2  COMPONENTS/TERMS 

1.2.3  INPUT  PRODUCTS 

1.2.4  GENERAL  PROCEDURES 

1.2. 4.1  LOGON  TO  IEW  PLANNING  WORKSTATION  FOR  LMVERIO  ENCYCLOPEDIA 
(SEE  LOGON  PROCEDURES) 

1.2. 4. 2  PULL  DOWN  “DISPLAY"  MENU 

1.2. 4. 3  SELECT  "ENTITY  DIAGRAM" 

1.2. 4. 4  "OPEN  AN  ENTITY  DIAGRAM  FOR  ONE  OF  THE  FOLLOWING"  WINDOW  IS 
DISPLAYED 

1.2. 4. 5  SELECT  "THE  ENTITY  MODEL" 

1.2. 4. 6  PRESS  "PROCEED"  KEY 

1.2. 4. 7  EXPAND  THE  DIAGRAM 

1.2. 4. 8  SELECT  (HIGHLIGHT)  THE  ENTITY  TYPES  OUTSIDE  THE  SCOPE 

1.2. 4. 8.1  SELECT  "CONTRACT" 

1.2. 4. 8. 2  SELECT  "LEGAL  ENTITY" 

1.2. 4. 8. 3  SELECT  "OFFER" 

1.2. 4. 8. 4  SELECT  "ITEM" 

1.2. 4. 9  PULL  DOWN  THE  "SELECT"  MENU 

1.2.4.10  SELECT  "HIDE  THESE" 

1.2.4.11  PRINT  THE  ENTITY  DIAGRAM 
(SEE  PRINT  INSTRUCTIONS) 

1.2.4.12  CLOSE  WINDOW 

1.2.4.13  ENTER  DIAGRAM  INTO  SECTION  XX  OF  THE  DATA  REQUIREMENTS 
DOCUMENT 
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1.2  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 

1.2  SELECT  CONCEPTUAL  ENTITIES 

Reference  Appendix  D,  GENERAL  PC  DICTIONARY  PROCEDURES,  for  more 
details  on  how  to  ADD,  EDIT,  DELETE,  COPY,  RENAME,  REPORT,  or  QUERY 
dictionary  members. 

1.2.1  PURPOSE 

The  purpose  in  these  PC  DICTIONARY  detailed  procedures  is  to  explain 
how  to  capture  and  report  the  information  that  is  gathered  while 
identifying  the  conceptual  entity  types  that  are  within  the  scope. 

1.2.2  COMPONENTS/TERMS 

1.2.3  INPUT  PRODUCTS 

1.2. 3.1  Conceptual  Data  Architecture  Entity  Relationship  Diagram  (ERD) 
See  IEW  Procedures. 

1.2. 3. 2  CDA  Entity  List 

(Get  list  of  Conceptual  Entities) 

1.2. 3. 2.1  Select  CATALOGUE  from  QUERY  MENU. 

1.2. 3. 2. 2  Select  query  logic,  EQUAL. 

1.2. 3. 2. 3  Enter  catalogue  name,  CONCEPTUAL,  or  select  from  look  up 
list  [F2] . 

1.2. 3. 2. 4  Check  report  destination  [ALT-F10]. 

1.2. 3. 2. 5  Start  query  [F10] . 

1.2. 3. 3  CDA  Entity  Report 

(Get  report  of  Entities  using  the  previous  list) 

1.2. 3. 3. 6  Select  MEMBER  DEFINITION  from  REPORT  MENU. 

1.2. 3. 3. 7  Select  member(s)  that  were  on  catalogue  query  report  [SPACE 
BAR]. 

1.2. 3. 3. 8  Check  report  destination  [ALT-F10] . 

1.2. 3. 3. 9  Print  report  [F10-G0] . 

1.2. 3. 4  Subject  Area  Information  Requirements  Reports  Reference  Section 

1.1  Output  Products. 

1.2.4  GENERAL  PROCEDURES 

1.2.4. 1  Review  CDA  Entities 
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1.2. 4. 2  Identify  Subject  Area  Entities 

1.2. 4. 2.1  Edit  each  Entity  that  has  been  selected  for  the  Subject 
Area. 

1.2. 4. 2. 2  Edit  the  CATALOG  attribute. 

1.2. 4. 2. 3  Add  the  CATALOG  ‘CONTRACTOR  PROFILE'. 

1.2. 4. 2. 4  Add  another  CATALOG  'ENTITY1. 

1.2. 4. 2. 5  Save  CATALOGS. 

1.2. 4. 2. 6  Edit  any  other  attributes,  as  needed. 

1.2. 4. 2. 7  Save  Entity. 

1.2.5  OUTPUT  PRODUCTS 

1.2. 5.1  Subject  Area  ERD 
See  IEW  Procedures 

1.2. 5. 2  Subject  Area  Entity  List 

(Get  list  of  Contractor  Profile  Entities) 

1.2. 5. 2.1  Select  CATALOGUE  from  QUERY  MENU. 

1.2. 5. 2. 2  Select  query  logic,  EQUAL. 

1.2. 5. 2. 3  Enter  catalogue  name,  CONTRACTOR  PROFILE,  or  select  from 
look  up  list  [F2]. 

1.2. 5. 2. 4  Select  query  logic,  EQUAL. 

1.2. 5. 2. 5  Enter  catalogue  name,  ENTITY,  or  select  from  look  up  list 
[F2] . 

1.2. 5. 2. 6  Check  report  destination  [ALT-F10] . 

1.2. 5. 2. 7  Start  query  [F10] . 

1.2. 5. 3  Subject  Area  Entity  Report 

(Get  report  of  Entities  using  previous  list) 

1.2. 5. 3. 8  Select  MEMBER  DEFINITION  from  REPORT  MENU. 

1.2. 5. 3. 9  Select  member(s)  that  were  on  catalogue  query  report  [SPACE 
BAR]. 

1.2.5.3.10  Check  report  destination  [ALT -F10] . 

1.2.5.3.11  Print  report  [F10-G0] . 
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1.3  SELECT  FUNCTIONS 


Figure  1.3-1  Step  Overview 
Figure  1.3-2  Step  Products 
Figure  1.3-3  Step  Components 


1.3.1  PURPOSE 

1.3.2  COMPONENTS/TERMS 

1.3. 2.1  Function 

1.3. 2. 2  Actions 

1.3. 2. 2. 2  Retrieve 

1.3. 2. 2. 3  Update 

1.3. 2. 2. 4  Delete 

1.3.3  INPUT  PRODUCTS 

1.3. 3.1  CIA  CRUD  Association  Matrix 

1.3. 3. 2  Objectives  Report 

1.3. 3. 3  Information  Requirements  Report 

1.3.4  GENERAL  PROCEDURES 

1.3. 4.1  Review  CRUD  Association  Matrix 

1.3. 4. 2  Delete  Out-of-scope  Functions 

1.3. 4. 3  Review  Subject  Area  Functions 

1.3.5  OUTPUT  PRODUCTS 


1.3. 5.1  LIA  Function  CRUD  Association  Matrix 

1.3. 5. 2  LIA  Function  Reports 

1.3.6  RULES 

1.3. 6.1  Adherence  to  scoping  criteria 

1.3. 6. 2  Mutual  exclusivity 

1.3. 6. 3  Exhaustiveness 

1.3. 6. 4  Naming  conventions  and  definitions 


1.3.7  EXAMPLES 


Figure  1.3. 7-1 

Figure  1.3. 7-2 
Figure  1.3. 7-3 

Figure  1.3. 7-4 
Figure  1.3. 7-5 

Figure  1.3. 7-6 
Figure  1.3. 7-7 
Figure  1.3. 7-8 


IEW  CIA  CRUD  Association  Matrix  (Two 
Levels  of  Functions) 

IEW  Function  Report  (Function  A) 

PCD  CIA  Functions  List  (Two  Levels  of 
Functions) 

PCD  Function  Report  (Function  A) 

IEW  LIA  Function  CRUD  Association  Matrix 
(Level  0  Functions  Only) 

IEW  LIA  Function  Report  (For  Function  AA) 
PCD  Function  Report  (For  Function  AA) 
Information  Requirements  Report 
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1.3  Appendix  A 
1.3  Appendix  B 


-  Detailed  IEW  Procedures 

-  Detailed  PC  Dictionary  Procedures 
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PRODUCTS 


COMPONENTS 


SCOPING 


1  SCOPING  1 

t.| 

\  Xy ■  ":r: 

oakiccnvKS 

h'  :  I 

scorwo 

w\ 

crtteru 

>.  1 

r 

H  FORMATION 
REQUIREMENTS 

.*..y 

t.  REVIEW  CRUO  ASSOCIATION  MATRIX 


7  OELETE  OUT-OF-SCOPE  FUNCTIONS 


3.  REVIEW  SUBJECT  AREA  FUNCTIONS 


INFORMATION  REQUIREMENTS  REPORT 


SCOPING 


FUNCTIONAL 

ARCHITECTURE 


MAPS 


DATA 

ARCHITECTURE 


1.3*2 


ENTITY  RELATIONSHIP  DIAGRAM 


1.3  SELECT  FUNCTIONS 


1.3.1  PURPOSE 

The  purpose  of  this  step  is  to  apply  the  scoping  criteria  to  the  CIA 
(Conceptual  Information  Architecture)  functions  in  order  to  select 
those  functions  out  of  the  CIA  which  will  be  decomposed  and  analyzed  in 
the  LIA  (Logical  Information  Architecture)  Global  Analysis  phase. 

The  reason  for  selecting  those  functions  which  are  within  scope  and  for 
deleting  those  which  are  out  of  scope  is  to  be  able  to  develop  a  set  of 
LIA  products  (diagrams,  reports,  and  documents)  which  contain  only 
those  components  which  are  involved  in  the  Subject  Area. 
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1.3.2  COMPONENTS/TERMS 

1.3. 2.1  Function 

A  function  is  a  major,  high-level  activity  of  an  enterprise,  comprising 
a  broad  group  of  processes  that  together  completely  support  one  aspect 
of  furthering  a  mission  of  an  enterprise.  Because  a  function  covers  a 
broad  group  of  activities,  it  is  not  normally  executable  or  executed  as 
a  whole;  its  component  processes  are  executed.  It  may  be  identified 
with  a  business  responsibility  but  not  with  an  organizational  unit.  A 
function  is  distinguishable  from  another  function  in  terms  of  expertise 
or  skills  required  to  perform  the  component  processes.  It  tends  to 
have  a  long  life  span,  subject  to  change  only  when  the  nature  of  the 
enterprise  changes.  Functions  are  identified  and  described  at  the 
conceptual  level  of  modeling.  Although  all  components  of  the 
functional  architecture  are  independent  of  organizational  structure, 
functions  tend  to  reflect  organizational  lines  because  enterprises  tend 
to  organize  themselves  into  groups  which  each  address  one  aspect  of 
furthering  the  mission  of  its  enterprise.  However,  organizations 
sometimes  form  functional  groupings  for  other  reasons,  such  as  remote 
locations,  resource  constraints,  etc.  To  avoid  building 
organizational,  geographical,  or  other  biases  into  the  functional 
models,  care  must  be  taken  to  analyze  functions  separated  from 
organizational  structure.  Decomposing  a  function  yields  its  component 
processes. 

1.3. 2. 2  Actions 

An  action  is  an  activity  which  occurs  within  a  process  on  an  entity, 
relationship,  attribute,  or  subprocess.  Actions  Create,  Retrieve, 
Update,  and  Delete  instances  of  entities  and  information  about 
entities. 


1.3. 2. 2.1  Create 

Creation  of  an  instance  of  an  entity  for  the  very  first  time. 

1.3. 2. 2. 2  Retrieve 

Read  instances  and  information  about  entities. 

1.3. 2. 2. 3  Update 

Updating  or  adding  any  new  information  to  an  already  existing  entity. 
Updating  information  about  an  entity  can  include  the  deletion  of 
existing  information  and  the  addition  of  new  information. 

1.3. 2. 2. 4  Delete 

Deleting  information  about  an  entity  or  deleting  instances  of  entities. 
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1.3.3  INPUT  PRODUCTS 


1.3. 3.1  CIA  CRUD  Association  Matrix 

The  CRUD  Association  Matrix  from  the  CIA  depicts  the  associations 
between  the  functions  and  the  entities  of  the  CIA.  See  Figure  1.3. 7-1. 

1.3. 3. 2  Objectives  Report 

The  Objectives  Report  (Figure  1.3. 7-9)  provides  the  objectives  which 
selected  functions  must  meet. 

1.3. 3. 3  Information  Requirements  Report 

The  Information  Requirements  Report  (Figure  1.3. 7-8)  provides  the 
information  requirements  which  selected  functions  must  address. 
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1.3.4  GENERAL  PROCEDURES 


1.3. 4.1  Review  CRUD  Association  Matrix 

Identify  the  functions  in  the  rows  on  the  CIA  CRUD  Association  Matrix. 
If  functions  are  not  identified  differently  than  processes,  then  apply 
the  definitions  and  rules  to  do  so.  Identify  functions  by  adding  "(F)" 
to  the  end  of  the  name  of  each. 

Also,  every  function  on  the  CRUD  Association  Matrix  should  have  the 
actions  of  its  subordinates  "rolled-up."  If  any  subordinate  functions 
or  processes  have  C,  R,  U,  and/or  D  indicated  for  an  entity,  then  the 
parent  should  also  have  the  CRUD  indicated  for  that  entity. 

1.3. 4. 2  Delete  Out-of-scope  Functions 

It  is  assumed  that  the  entities  which  are  not  within  the  scope  of  the 
Subject  Area  have  been  deleted  from  the  LIA. 

It  is  also  assumed  that  all  functions  which  use  entities  are  properly 
indicated  with  C,  R,  U,  or  D  properties.  If  subordinate  functions  have 
CRUD  properties  then  the  parent  should  also  have  those  properties. 

Delete  those  functions  within  the  CRUD  Association  Matrix  which  do  not 
use  the  entities  which  have  been  selected  as  being  within  the  scope  of 
the  subject  area;  delete  those  functions  which  do  not  contain  any  (C, 

R,  U,  or  D)  in  their  rows. 

If  one  of  the  scoping  criteria  is  to  exclude  those  functions  which  do 
not  perform  specific  "actions"  (e.g.,  Create,  Retrieve,  Update,  or 
Delete),  then  also  delete  those  functions. 

If  any  processes  are  shown  on  the  CRUD  Association  Matrix  then 
"exclude"  these  (do  not  “delete"). 

Review  the  definitions  of  each  function  and  apply  the  scoping 
"objectives"  to  determine  whether  the  function  uses  the  selected 
entities.  Delete  those  functions  which  do  not  use  the  selected 
entities.  Only  those  functions  which  are  within  the  scope  of  the 
subject  area  now  remain  in  the  CRUD  Association  Matrix.  These 
functions  are  associated  with  the  entities  which  are  within  the  scope. 
This  is  the  Logical  Information  Architecture  (LIA)  CRUD  Association 
Matrix  for  functions. 

1.3. 4. 3  Review  Subject  Area  Functions 

Produce  reports  with  the  selected  subject  area  functions  and  their 
definitions.  Review  the  definitions  for  completeness  and  accuracy 
while  making  sure  that  the  functions  pertain  to  the  subject  area. 
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1.3.5  OUTPUT  PRODUCTS 

1.3. 5.1  LIA  Function 

1.3. 5. 2  LIA  Function 


CRUD  Association  Matrix 
Reports 
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1.3.6  RULES 


1.3. 6.1  Adherence  to  scoping  criteria 

All  chosen  Functions  must  follow  the  scoping  criteria  (selected 
objectives  and  information  requirements). 

1.3. 6. 2  Mutual  exclusivity 

All  functions  must  be  mutually  exclusive  at  the  same  level  of  their 
respective  hierarchy. 

1.3. 6. 3  Exhaustiveness 

All  functions  at  one  level  of  a  hierarchy  must  completely  exhaust  the 
parent  function. 

1.3. 6. 4  Naming  conventions  and  definitions 

All  functions  must  follow  the  component  definitions  and  naming 
conventions:  Functions  names  are  nouns. 
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1.3.7  EXAMPLES 


Figure  1.3. 7-1 

Figure  1.3. 7-2 
Figure  1.3. 7-3 
Figure  1.3. 7-4 
Figure  1.3. 7-5 

Figure  1.3. 7-6 
Figure  1.3. 7-7 
Figure  1.3. 7-8 
Figure  1.3. 7-9 


IEW  CIA  CRUD  Association  Matrix  (Two  Levels  of 
Functions) 

IEW  Function  Report  (Function  A) 

PCD  CIA  Functions  List  (Two  Levels  of  Functions) 
PCD  Function  Report  (Function  A) 

IEW  LIA  Function  CRUD  Asspciation  Matrix  (Level  0 
Functions  Only) 

IEW  LIA  Function  Report  (For  Function  AA) 

PCD  Function  Report  (For  Function  AA) 

Information  Requirements  Report 
Objectives  List 


92 


A  ACQUISITION  (F) 


AA  PURCHASE  REQ  PROCESSING  (F) 


AS  OFFER  EVALUATION  (F) 


AC  CONTRACT  AWARD  (F) 


AC  CONTRACT  ADMINISTRATION  (F) 


AE  FORWARD  PRICE  RATE  OEV  (F) 


AF  CONTRACTOR  SYSTEM  REVIEW  (F) 


8  INDUSTRIAL  PREP  PUWING  (F) 


8A  MOBILIZATION  REQ'fENT  OET  (F) 


'  38  IPP  CANDIDATE  ITEM  IDENT  (F) 


’  8C  PROO  PLACING  SCK3  DEV  (F) 


DEVELOP  IPP  PACKAGE  (F) 


PrjSIII  i  nvolvll  Entity  T  y  p  < 


February  13.  1  JSO  11:01:37 


Figure  1.3. 7-1  IEW  CIA  CRUD  Association  Matrix 
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Information  Engineering  Workbench  Report 

Object  Summary  Report 

July  3,  1990  9:14:00  NEWUSER  VOS 

Process  A  ACQUISITION  (F) 

PROPERTIES: 

DEFINITION: 

ACQUISITION  CONSISTS  OF  THE  FOLLOWING  FUNCTIONS 

AA  PURCHASE  REQUEST  PROCESSING 
AB  OFFER  EVALUATION 
AC  CONTRACT  AWARD 
AD  CONTRACT  ADMINISTRATION 
AE  FORWARD  PRICE  RATE  DEVELOPMENT 
AF  CONTRACTOR  SYSTEM  REVIEW 


Figure  1.3. 7-2  IEW  Funrfion  Report  (Function  A) 
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I 

I  DEFENSE  LOGISTICS  AGENCY 

07/02/90  Catalogue  Query 

The  following  members  satisfy  this  condition... 
FUNCTION  AND  LIFE  CYCLE  FUNCTION. 

Member  Type 


|  FN-ACQST 

FUNCTION 

1 

FN-CAND-ITEM-IDNTF 

FUNCTION 

|  FN-CNTRC-SYS-RVU 

FUNCTION 

FN-CONTR-ADMIN 

| 

FUNCTION 

I  FN-CONTR-AWARD 

FUNCTION 

■  FN- FWD- PR I C  E -RATE - DVPMT 

FUNCTION 

*  FN-INDST-PREP'-PLANG 

FUNCTION 

|  FN-OFFER-EVALN 

FUNCTION 

FN-PKG-DVPMT 

m 

FUNCTION 

|  FN-POST-PLANG 

FUNCTION 

-  FN-PRCH-RQST-PRCNG 

FUNCTION 

■  FN-PRE-PLANG 

FUNCTION 

■  12  Member (s)  Satisfying  Catalogue  Query 

I 

I 

I 

I 

I 

I 

Figure  1.3. 7-3  PCD  CIA  Functions  List 

I 


■ 


Member  Name 
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07/02/90 
Member  Type 
Member  Name 


FUNCTION 

FN-ACQST 


DEFENSE  LOGISTICS  AGENCY 

Member  Definition  Report  Pa9e  * 

Attribute  Name  &  Contents 


ALIAS 

IEW  A  ACQUISITION  (F) 

CATALOGUE 

FUNCTION 

LIFE  CYCLE  FUNCTION 
DEFINITION 

THIS  FUNCTION  EXISTS  FOR  THE  FOLLOWING  PURPOSES: 

1.  TO  PROCESS  PURCHASE  REQUESTS. 

2.  TO  EVALUATE  OFFERS. 

3.  TO  AWARD  CONTRACTS. 

4.  TO  ADMINISTER  CONTRACTS. 

5.  TO  DEVELOP  FORWARD  PRICE  RATE. 

6.  TO  REVIEW  CONTRACTOR  SYSTEM. 

DESCRIPTION 

ENTRY-CONTENT-APPROVER -ORG 
ENTRY-CONTENT-MAINTAINER-QRG 
FULL-NAME 
ACQUISITION 
SOURCE 

OECOMPOSITION-TEXT 

CONTAINS 

SEE 

FN-4-0-C0NTR 
FOR  "BAA  FUNCTION" 

FN-5-0-C0NTR-ADMIN 
FOR  "BAM  FUNCTION" 


Figure  1.3. 7-4  PCD  Function  Report  (Function  A) 
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AA  PURCHASE  RED  PROCESSING  (F) 

AB  OFFER  EVALUATION  (F) _ 

AC  CONTRACT  AttARO  (F) _ 

AO  CONTRACT  ADMINISTRATION  (F) 

AE  FORWARD  PRICE  RATE  DEV  (F) 

A F  CONTRACTOR  SYSTEM  REVIEW  (F) 
BA  MOBILIZATION  REQ'lENT  DET  (F) 
BB  IPP  CANDIDATE  ITEM  IOENT  (F) 
BC  PROO  PLACING  SCHD  OEV  (F) 

SO  DEVELOP  IPP  PACKAGE  (F) 


R 

R 

CRU 

CPU 

R 

CRU 

R 


R 

RU 

CRU 

CRU 

CRU 

CRU 

RU 

RU 

RU 

R 


f  rocni  involves  Entity  Typo 


Figure  1.3. 7-5  IEW  LIA  Function  CRUD  Association  Matrix 
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Information  Engineering  Workbench  Report 
Object  Summary  Report 

February  13,  1990*  10:50:08  NEWUSER  PLIATK 
Process  AA  PURCHASE  REQ  PROCESSING  (F) 
PROPERTIES : 

LAST  UPDATE:  1990/02/13  10:49  NEWUSER 
CREATED:  1989/06/15  11:05:25  NEWUSER 
DEFINITION: 

1.  Assure  adequacy  of  PR. 

2.  Develop  Strategy  for  acquisition 

3 .  Prepare  Acquisition  Plan 

4.  Prepare  Solicitation 

ASSOCIATIONS: 

HAS 

External  Agent  NCN-DLA  ACTIVITY 
INVOLVES 

Entity  Type  CONTRACT 

ASSOCIATION  PROPERTIES: 

ACTION:  R 

Entity  Type  LEGAL  ENTITY 

ASSOCIATION  PROPERTIES: 

ACTION:  R 
IS  COMPOSED  OF 

Process  AAA  ASSURE  ADEQUACY  OF  PR 
Process  AAB  DEVELOP  STRATEGY  FOR  ACQ 
Process  AAC  PREPARE  ACQUISITION  PLAN 
Process  AAD  PREPARE  SOLICITATION 


Figure  1.3. 7-6  IEW  LIA  Function  Report  (For  Function  AA) 


Page  1 


98 


07/02/90 
Member  Type 
Member  Name 


FUNCTION 

FN-PRCH-RQST 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 

Attribute  Name  &  Contents 


■PRCNG  ALIAS 

IEW  AA  PURCHASE  REQ  PROCESSING  (F) 

CATALOGUE 

CONTRACTOR  PROFILE 
FUNCTION 

LIFE  CYCLE  FUNCTION 
DEFINITION 

THIS  FUNCTION  EXISTS  FOR  THE  FOLLOWING  PURPOSES: 

1.  TO  ASSURE  ADEQUACY  OF  PR. 

2.  TO  DEVELOP  STRATEGY  FOR  ACQUISITION. 

3.  TO  PREPARE  ACQUISITION  PLAN. 

4.  TO  PREPARE  SOLICITATION. 

DESCRIPTION 

ENTRY-CONTENT-APPROVER-ORG 
ENTRY-CONTENT -MAINTAINER-ORG 
FULL -NAME 

PURCHASE  REQUEST  PROCESSING 
SOURCE 

DECOMPOSITION-TEXT 

CONTAINS 

PR-ASSUR-PRCH-RQST -ADQCY 

PR -DE VLP - ACQST -STRTG 

PR-PREP-ACQST -PLAN 

PR-PREP-SOLCN 

SEE 

FN-4- 1 -PERFM-PRE -AWARD-PLAN 
FOR  "BAA  FUNCTION" 

FN-4-2-S0LCT-0FFE 
FOR  "BAA  FUNCTION’ 

EN-CONTR 
FOR  "Read" 

EN-ITEM 

FOR  "Read/Update" 

EN-LEGAL-ENTY 

FOR  "Create/Read/Update/Delete" 


Figure  I. 3. 7-7  PCD  Function  Report  (For  Function  AA) 


Page  1 
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07/02/90 
Member  Type 
Member  Name 


INFORMATION-REQUIREMENT 

IR-OOUi 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 

Attribute  Name  &  Contents 


CATALOGUE 

CONTRACTOR  PROFILE 
DEFINITION 

Contractors  should  track  subcontractors  performance. 
ENTRY-CONTENT-APPROVER-ORG 
FULL-NAME 
SOURCE 
CONTAINS 


Figure  1.3. 7-8  Information  Requirements  Report 


Page  1 
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DEFENSE  LOGISTICS  AGENCY 

07/02/90  Member  Definition  Report  Page  1 

Member  Type 

Member  Name  Attribute  Name  &  Contents 


OBJECTIVE 

OBJ-OOOOl -OBTN-SFCNT-ESN-MTL  CATALOGUE 

DEFINITION 

Obtain  sufficient  essential  materiel  to  meet  readiness  and  sustainability 
requirements  for  the  full  spectrum  of  operating  scenarios. 
ENTRY-CONTENT-APPROVER-ORG 
FULL -NAME 

Obtain  Sufficient  Essential  Materiel 
SOURCE 

DLA  1988  Strategic  Plan,  page  32 


Figure  1.3. 7-9  Objectives  Report 


1.3  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 
1.3  SELECT  FUNCTIONS 

There  are  no  IEW  procedures  for  this  section. 
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1.3  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 

1.3  SELECT  FUNCTIONS 

Reference  Appendix  D,  GENERAL  PC  DICTIONARY  PROCEDURES,  for  more 
details  on  how  to  ADD,  EDIT,  DELETE,  COPY,  RENAME,  REPORT,  or  QUERY 
dictionary  members. 

1.3.1  PURPOSE 

The  purpose  in  these  PC  DICTIONARY  detailed  procedures  is  to  explain 
how  to  capture  and  report  the  information  that  is  gathered  while 
identifying  the  functions  that  are  within  the  scope. 

1.3.2  COMPONENTS/TERMS 

1.3.3  INPUT  PRODUCTS 

1.3. 3.1  CIA  CRUD  Association  Matrix 
See  IEW  Procedures. 

1.3. 3. 2  Information  Requirements  Reports  Reference  Section  1.2  Output 
Products. 

1.3. 3. 3  Objective  Report  Reference  Section  1.2  Output  Products. 

1.3.4  GENERAL  PROCEDURES 

1.3. 4.1  Review  CIA  CRUD  Association  Matrix 

1.3. 4. 2  Delete  Out-of-Scope  Functions 

1.3. 4. 2.1  Edit  each  Function  that  has  been  selected  for  the  Subject 
Area. 

1.3. 4. 2. 2  Edit  the  CATALOG  attribute. 

1.3. 4. 2. 3  Add  the  CATALOG  'CONTRACTOR  PROFILE'. 

1.3. 4. 2. 4  Add  another  CATALOG  'FUNCTION'. 

1.3. 4. 2. 5  Save  CATALOGS. 

1.3. 4. 2. 6  Edit  any  other  attributes,  as  needed. 

1.3. 4. 2. 7  Save  Function. 

1.3. 4. 3  Review  Subject  Area  Functions 
1.3.5  OUTPUT  PRODUCTS 

1.3. 5.1  LIA  Function  CRUD  Association  Matrix 


See  IEW  Procedures. 


1.3. 5. 2  LIA  Function  Reports 
(Get  list  of  Subject  Area  Functions) 

1.3. 5. 2.1  Select  CATALOGUE  from  QUERY  MENU. 

1.3. 5. 2. 2  Select  query  logic,  EQUAL. 

1.3. 5. 2. 3  Enter  catalogue  name,  CONTRACTOR  PROFILE,  or  select  from 
look  up  list  [F2]. 

1.3. 5. 2. 4  Select  query  logic,  EQUAL. 

1.3. 5. 2. 5  Select  query  logic,  EQUAL. 

1.3. 5. 2. 6  Enter  catalogue  name,  FUNCTION,  or  select  from  look  up  list 

[F2] . 

1.3. 5. 2. 7  Check  report  destination  [ALT-F10]. 

1.3. 5. 2. 8  Start  query  [F10]. 

(Get  report  of  Subject  Area  Functions) 

1.3. 5. 2. 9  Select  MEMBER  DEFINITION  from  REPORT  MENU. 

1.3.5.2.10  Select  member(s)  that  were  on  catalogue  query  report  [SPACE 
BAR]. 

1.3.5.2.11  Check  report  destination  [ALT-F10]. 

1.3.5.2.12  Print  report  [F10-G0]. 
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1.4  PREPARE  SCOPE  MEMORANDUM 


Figure  1.4-1  Step  Overview 
Figure  1.4-2  Step  Products 
Figure  1.4-3  Step  Components 

1.4.1  PURPOSE 

1.4.2  COMPONENTS 

1.4.2. 1  Objective 

1.4. 2. 3  Information  Requirement 

1.4. 2. 3  Entity 

1.4. 2. 4  Process 

1.4.3  INPUT  PRODUCTS 

1.4. 3.1  Subject  Area  Objective  Report 

1.4. 3. 2  Subject  Area  Information  Requirements  Report 

1.4. 3. 3  Subject  Area  Entity  Relationship  Diagram 

1.4. 3. 4  Subject  Area  Entity  Reports 

1.4. 3. 5  Subject  Area  Function  Decomposition  Diagram 

1.4. 3. 6  Subject  Area  Function  Report 

1.4.4  GENERAL  PROCEDURES 

1.4. 4.1  Gather  Suppporting  Documentation 

1.4. 4. 2  Prepare  OLA-IOM 

1.4.5  OUTPUT  PRODUCTS 

1.4. 5.1  Subject  Area  Scope  IOM 

1.4.6  RULES 

1.4.7  EXAMPLES 

Figure  1.4. 7-1  Subject  Area  Objective  Report 
Figure  1.4. 7-2  Subject  Area  Information  Requirements 
Report 

Figure  1.4. 7-3  Subject  Area  Entity  Relationship  Diagram 
Figure  1.4. 7-4  Subject  Area  Entity  Reports 
Figure  1.4. 7-5  Subject  Area  Function  Decomposition 
Diagram 

Figure  1.4. 7-6  Subject  Area  Function  Report 
Figure  1.4. 7-7  Subject  Area  Scope  IOM 

1.4  Appendix  A  -  Detailed  IEW  Procedures 

1.4  Appendix  B  -  Detailed  PC  Dictionary  Procedures 
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PRODUCTS 


COMPONENTS 


FIGURE  1.4-1 
STEP  OVERVIEW 
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1.4  PREPARE  SCOPE  MEMORANDUM 
1.4.1  PURPOSE 

To  document  the  scope  of  the  Subject  Area  for 

-  management  review  and  approval 

-  setting  the  proper  expectation 


109 


1.4.2  COMPONENTS 


1.4. 2.1  Objective 

1.4. 2. 3  Information  Requirement 

1.4. 2. 3  Entity 

1.4. 2. 4  Process 

1.4.3  INPUT  PRODUCTS 

1.4. 3.1  Subject  Area  Objective  Report  (Figure  1.4. 7-1) 

1.4. 3. 2  Subject  Area  Information  Requirements  Report  (Figure  1.4. 7-2) 

1.4. 3. 3  Subject  Area  Entity  Relationship  Diagram  (Figure  1.4. 7-3) 

1.4. 3. 4  Subject  Area  Entity  Reports  (Figure  1.4. 7-4) 

1.4. 3. 5  Subject  Area  Function  Decomposition  Diagram  (Figure  1.4. 7-5) 

1.4. 3. 6  Subject  Area  Function  Report  (Figure  1.4. 7-6) 

1.4.4  GENERAL  PROCEDURES 

1.4. 4.1  Gather  Supporting  Documentation 

Gather  copies  of  the  products  listed  as  inputs.  These  will  be 
attachments  to  a  DLA  IOM  prepared  in  the  next  step.  These 
attachments  contain  the  Project  Team's  recommendation  on  scope. 

The  Project  Team  may  choose  to  also  gather  products  that  represent  the 
Conceptual  Architecture  so  that  what  is  in  scope  and  what  is  not  in 
scope  will  be  apparent. 

1.4. 4. 2  Prepare  DLA- IOM 

An  IOM  is  prepared  that  explains  the  purpose  of  the  memo  and  the 
attachments.  The  memo  should  be  addressed  to  the  Program  Manager 
from  the  Team's  leader.  The  Program  Manager  will  coordinate  the  IOM 
for  comments,  review  meetings  and  ultimately  approval. 

The  memo  should  identify  the  scheduled  date  for  completing  Global 
Analysis.  Any  changes  to  scope  beyond  this  date  will  generally  result 
in  significant  rework  which  translates  into  cost  overruns  and 
slipped  schedules. 

After  completing  the  memo,  the  Team  will  be  expected  to  proceed 
directly  into  Global  Analysis  without  waiting  for  approval.  Changes 
received  during  Global  Analysis  will  require  the  Team  to  retrace 
Global  Analysis  steps. 
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1.4.5  OUTPUT  PRODUCTS 

1.4. 5.1  Subject  Area  Scope  IOM  (Figure  1.4. 7-7) 
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1.4.6  RULES 


I 

I 

I 

I 

I 
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1.4.7  EXAMPLES 


Figure  1.4. 7-1  Subject  Area  Objective  Report 

Figure  1.4. 7-2  Subject  Area  Information  Requirements  Report 

Figure  1.4. 7-3  Subject  Area  Entity  Relationship  Diagram 

Figure  1.4. 7-4  Subject  Area  Entity  Reports 

Figure  1.4. 7-5  Subject  Area  Function  Decomposition  Diagram 

Figure  1.4. 7-6  Subject  Area  Function  Report 

Figure  1.4. 7-7  Subject  Area  Scope  10M 
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DEFENSE  LOGISTICS  AGENCY 

07/02/90  Member  Definition  Report  Page  1 

Member  Type 

Member  Name  Attribute  Name  &  Contents 


OBJECTIVE 

OB-PROV-CNTRC-PRFMC-DATA  CATALOGUE 

CONTRACTOR  PROFILE 
OBJECTIVE 
DEFINITION 

Provide  contractor  performance  data  in  order  to  award  contracts  to  the 
best  performing  contractors. 

ENTRY-CONTENT -APPR0VER-0RG 
FULL-NAME 

Provide  Contractor  Performance  Data 
SOURCE 

Team  member  knowledge 


Figure  1.4. 7-1  Subject  Area  Objective  Report 


07/02/90 
Member  Type 
Member  Name 


INFORMATION-REQUIREMENT 

IR-CNTRC-CHARC 


INFORMATION-REQUIREMENT 

IR-CNTRC-CONTR-PRFMC 


DEFENSE  LOGISTICS  AGENCY 

Member  Definition  Report  Page  1 

Attribute  Name  &  Contents 


CATALOGUE 

CONTRACTOR  PROFILE 
INFORMATION  REQUIREMENT 
DEFINITION 

Information  which  identifies  and  describes  a  given  contractor's  resources 
and  their  locations. 

ENTRY-CONTENT-APPROVER -ORG 
FULL-NAME 

Contractor  Characteristics 
SOURCE 

Team  member  knowledge 
CONTAINS 
EN-ITEM 

EN-LEGAL-ENTY 

EN-OFFER 

IR-0021 

IR-0022 


CATALOGUE 

CONTRACTOR  PROFILE 
INFORMATION  REQUIREMENT 
DEFINITION 

Information  which  indicates  a  given  contractor's  effectiveness  and 
efficiency  to  satisfy  contractual  obligations.  This  information 
indicates  performance  on  items,  performance  on  an  individual  contract, 
aggregate  performance  on  multiple  contracts,  or  performance  with  other 
Government  customers  and/or  non-Government  clients. 

ENTRY-CONTENT- APPROVER -ORG 
FULL-NAME 

Contractor  or  Contract  Performance 
SOURCE 

Team  member  knowledge 
CONTAINS 
EN-CONTR 

EN-ITEM 

EN-LEGAL-ENTY 

IR-0001 

IR-0002 
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07/02/90 
Member  Type 
Member  Name 

IR-0004 
IR-0010 
IR-0016 
IR -001 7 
IR-0021 
IR-0022 
IR -0038 
IR-0040 
IR-0041 
IR-0045 
IR -0048 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 

Attribute  Name  &  Contents 


Figure  1.4. 7-2  Subject  Area  Information  Requirements  Report 


Page  2 
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OOVAO  -  CON  T  R - ROI  E 


Figure  1.4. 7-3  Subject  Area  Entity  Relationship  Diagram 


07/02/90 
Member  Type 
Member  Name 


ENTITY 

EN-CONTR 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 

Attribute  Name  &  Contents 


Page  1 


ALIAS 
CATALOGUE 
CONCEPTUAL 
CONTRACTOR  PROFILE 
ENTITY 
SUBSTANTIVE 
DEFINITION 

A  contract  is  a  mutually  binding  legal  instrument  obligating  the  seller 
to  furnish  the  supply,  service,  or  data  items  and  the  buyer  to  pay  for 
them. 

DESCRIPTION 

In  addition  to  bilateral  instruments,  contracts  include  (but  are  not 
limited  to)  job  orders  or  task  letters  issued  under  basic  oroer 
agreements;  letter  contracts;  orders,  such  as  purchase  orders,  under 
which  the  contract  becomes  effective  by  written  acceptance  or 
performance. 

ENTRY-CONTENT-APPROVER-ORG 

ENTRY-CONTENT-MAINTAINER-ORG 

FULL-NAME 

Contract 

SOURCE 

Team  member  knowledge 
FAR  suboart  2.1 
IDENTIFIER  IS 
CT-CONTR-NBR 
MULTI -ASSOCIATION  TO 
MULTI-ATTRIBUTES  ARE 
ONE -ASSOCIATION  TO 
ONE-ATTRIBUTES  ARE 
CT-CONTR-CLOSD-DATE 

CT-CONTR-DOLR-AMT 

CT-CONTR-EFCTV-AWARD-DATE 

CT-CONTR-PAYMT-TERM-TEXT 

CT-CONTR-DPAS-RATE-CD 

CT-CONTR-STAT-INOCT 

CT-C0NTR-0BGD-D0LR-AMT 

SEE 

SUB-ENTITIES  ARE 
EN-CONTR -MOD 

EN-CLAUS 

EN-SOW-ELMNT 
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07/02/90 
Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 


Page  2 


Attribute  Name  &  Contents 


EN-LNITM 


ENTITY 

EN-LENTY 


I 

I 

I 

I 

I 

I 

I 

I 


ALIAS 
CATALOGUE 
CONCEPTUAL 
CONTRACTOR  PROFILE 
ENTITY 
SUBSTANTIVE 
DEFINITION 

Legal  entity  is  a  person  or  group  of  persons,  a  corporation  or  other 
existence  recognized  by  law  as  having  rights  and  duties. 

DESCRIPTION 

This  includes  current  contractor,  past  contractor,  potential  contractor, 
or  offeror. 

ENTRY-CONTENT-APPROVER-ORG 
ENTRY -CONTENT -MAI NTAINER-ORG 
FULL-NAME 

LEGAL -ENTITY 
SOURCE 

Dictionary 

Team  member  knowledge 
IDENTIFIER  IS 
CT-LENTY-NBR 
MULTI -ASSOCIATION  TO 
MULTI-ATTRIBUTES  ARE 
CT-LENTY-FAX-NBR 

CT-LENTY-SIC-CD 

CT-LENTY-TLPHN-NBR 
ONE-ASSOCIATION  TO 
ONE-ATTRIBUTES  ARE 
CT-LENTY-BKRCY-CD 

CT-LENTY-BUSNS-SIZE 

CT-LENTY-DB-RATE-DATE 

CT-LENTY-NAME 

CT-LENTY-OWNSP-CD 

CT -LENTY-PARNT - IONTF 

CT-LENTY-STAT-CD 

CT-LENTY-TAX-ID-NBR 
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I 


07/02/90 
Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 


Page 


Attribute  Name  &  Contents 

CT-LENTY-BUSNS-ADRS-TEXT 

CT-LENTY-D8-RATE-CD 

CT-LENTY -D I SCL -  STMT -ST  AT- 1 NDCT 

CT-LENTY-ELGBY-STAT-INDCT 

CT -LENTY-MALNG-ADRS-TEXT 

CT -LENTY -NOVTN-STAT -CD 

CT-LENTY-ASSN-CAGE-CD 

CT-LENTY -CAGE -CD 

CT-LENTY-WOMAN-OWNSP-INDCT 

CT -LENTY -DISAD- INDCT 

CT-LENTY -MNRTY-INDCT 
SEE 

EN-SRC 

EN-OFRR 

EN-CNTRC 

EN-SUB-CNTRC 

EN-PRE-AWD-SURVY-RQST 

EN-CAPBL 

EN-CNTRC-HIST 

EN-CNTRC-SYS 

EN-CNTRC-CORTV-ACTN 

EN-CONTR-QLTY-ASRNC 

EN-FINDG 

EN-FWD-PRICE-RATE 

EN-PRCDR-EVAL 

EN-PRCDR-RVU 
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07/02/90 
Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 
Mentier  Definition  Report 


Page 


Attribute  Name  &  Contents 


EN-QLTY-DATA-EVAL 

EN-SRVLC 

EN-CONTR 

FOR  "ASSOCIATION" 
EN-ITEM 

FOR  "ASSOCIATION" 
EN-OFFER 

FOR  "ASSOCIATION" 
EN-SOLCN 

FOR  "ASSOCIATION" 
SUB-ENTITIES  ARE 
EN-LENTY-CBLTY 

EN-LENTY-PRFMC-PLACE 

EN-LENTY-SYS-RVU 


Figure  I. 4. 7-4  Subject  Area  Entity  Report 
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PURCHASE 

DEO 

PROCESS! NO 


igure  1.4. 7-5  Subject  Area  Function  Decomposition  Diagram 


DEFENSE  LOGISTICS  AGENCY 
07/02/90  Member  Definition  Report 
Member  Type 

Member  Name  Attribute  Name  &  Contents 


FUNCTION 

FN-ACQST  ALIAS 

IEW  A  ACQUISITION  (F) 

CATALOGUE 

FUNCTION 

LIFE  CYCLE  FUNCTION 
DEFINITION 

THIS  FUNCTION  EXISTS  FOP.  THE  FOLLOWING  PURPOSES: 

1.  TO  PROCESS  PURCHASE  REQUESTS. 

2.  TO  EVALUATE  OFFERS. 

3.  TO  AWARD  CONTRACTS. 

4.  TO  ADMINISTER  CONTRACTS. 

5.  TO  DEVELOP  FORWARD  PRICE  RATE. 

6.  TO  REVIEW  CONTRACTOR  SYSTEM. 

DESCRIPTION 

ENTRY-CONTENT-APPROVER-ORG 

ENTRY-CONTENT-MAINTAINER-ORG 

FULL-NAME 

ACQUISITION 

SOURCE 

DECOMPOSITION-TEXT 

CONTAINS 

SEE 

FN-4-0-C0NTR 
FOR  "BAA  FUNCTION" 

FN-5-O-CONTR-ADMIN 
FOR  'BAA  FUNCTION" 


Figure  1.4. 7-6  Subject  Area  Function  Report 


Page  1 
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CONTRACTOR  PROFILE  PILOT  TEAM 

SUBJECT:  Memorandum  of  Scoping  for  Logical  Information  Architecture 
(Contractor  Profile  Pilot) 

TO:  DSMG-PK 

ATTN:  LTC  Kike  Hodges ,  Program  Manager 


1.  Reference:  Logical  Information  Architecture  (LIA)  Developmen 
Procedures  Draft,  February  1990,  Section  1.4  (enclosure  1,  PR.EPAR 
SCOPE  MEMORANDUM) . 

2.  Purpose:  The  purposes  of  the  Scoping  Phase  cf  the  LIA 
DeveloDmer.t  Procedures  include  the  following: 

a.  To  develop  the  scoping  criteria  for  selecting  components 
out  cf  the  Conceptual  Information  Architecture  which  will  be 
analvzed  and  designed  during  the  Logical  Information  Architecture 
Development  Phase.  The  scotinc  criteria  consist  cf  Information 


3.  Explanation  of  attachments : 

The  following  steps  were  performed  to  produce  the  attachments 
(products)  required  to  complete  the  Scoping  Phase: 

a.  The  Pilot  team  reviewed  the  Conceptual  Information 
Architecture  (CIA)  (enclosure  2,  CIA  ASSOCIATION  MATRIX).  This 
matrix  shows  the  conceptual  entities,  functions  and  processes  which 
constitute  the  entire  CIA. 

b.  Identified,  collected  and  reviewed  source  documents 
(enclosure  3,  LIST  CF  SCOPING  SOURCE  DOCUMENTS). 
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CONTRACTOR  PROFILE  PILOT  TEAM  PAGE  2 

SUBJECT:  Memorandum  of  Scoping  for  Logical  Information  Architecture 


c.  Defined  detailed  Information  Requirements  (IR's)  (enclosure 
4 ,  DETAILED  INFORMATION  REQUIREMENTS ) . 

d.  Defined  high-level  Information  Reauirements  (enclosure  5, 
HIGH-LEVEL  INFORMATION  REQUIREMENTS). 

e.  Defined  the  Objective  of  the  Contractor  Profile  Subject  Area 
(enclosure  6,  OBJECTIVE  OF  THE  CONTRACTOR  PROFILE  SUBJECT  AREA). 

f .  Applied  the  scoping  criteria  to  the  Conceptual  Data 
Architecture  and  selected  the  conceptual  entities  which  are  within 
the  scope  of  the  Logical  Data  Architecture  (enclosure  7,  CONCEPTUAL 
ENTITY  RELATIONSHIP  ^DIAGRAM,  enclosure  8,  SELECTED  ENTITY 
RELATIONSHIP  DIAGRAM,  enclosure  9,  SELECTED  ENTITY  REPORT). 

g.  Applied  the  scoping  criteria  to  the  Conceptual  Functional 
Architecture  and  selected  the  functions  which  are  within  the  scone 
of  the  Logical  Functional  Architecture,  (enclosure  10,  CONCEPTUAL 
FUNCTION  TO  ENTITY  ASSOCIATION  MATRIX,  enclosure  11,  SELECTED 
FUNCTION  TO  ENTITY  ASSOCIATION  MATRIX,  enclosure  12,  SELECTED 
FUNCTION  REPORT). 

4 .  Recommendations : 

a.  The  Pilot  Team  recommends  that  the  objective  of  the 
Contractor  Profile  Pilot  Logical  Information  Architecture  be  as 
follows : 

"Provide  contractor  performance  data  in  order  to  award  contracts  to 
the  best  performing  contractors.” 

b.  The  Pilot  team  recommends  that  the  high  level  information 
requirements  to  be  fulfilled  by  the  Contractor  Profile  Pilot  are  as 
follows : 

(1)  Contract  or  Contractor  Performance 

"Information  which  indicates  a  given  contractor's  effectiveness  and 
efficiency  to  satisfy  contractual  obligations.  This  information 
indicates  performance  on  items,  performance  on  an  individual 
contract,  aggregate  performance  on  multiple  contracts,  or 
performance  with  other  Government  customers  and/or  non-Government 
clients  .  " 

(2)  Contractor  Capability 

"Information  which  identifies  and  describes  a  contractor's  ability 
and  capacity  to  provide  a  service  or  a  product." 
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CONTRACTOR  PROFILE  PILOT  TEAM  PAGE  3 

SUBJECT:  Memorandum  of  Scoping  for  Logical  Information  Architecture 


(3)  Contractor  Characteristics 

"Information  which  identifies  and  describes  a  given  contractor's 
resources  and  its  location ( s ). " 

(4)  Information  Requirements  not  to  be  included 
(definitions  listed  in  enclosure  13). 

(a)  Bids  and  Proposals 

(b)  Contract  Requirements 

(c)  Item 

(d)  Government  Performance 

c.  The  Pilot  team  has  applied  the  scoping  criteria  according  to 
the  scoping  procedures,  selected  the  entities,  and  recommends  that 
the  following  entities  (as  defined  in  enclosure  9,  SELECTED  ENTITY 
REPORT)  be  included  within  the  scope  of  the  Logical  Data 
Architecture : 

(1)  Legal  Entity 

( 2 )  Contract 

(3)  Offer 

(4)  Item 

The  following  entities  are  not  within  the  scope  cf  the  Contraccor 
Profile  Pilot  Logical  Information  Architecture  because  they  dc  net 
contain  atrributes  relative  to  the  selected  contractor  performance, 
capability  and  characteristics  Information  Requirements  and 
Objective.  Entities  not  included  are  as  follows  (defir.irions  listed 
in  enclosure  14): 

( 5 )  Employee 

(6)  Solicitation 

(7)  Organization 

( 8 )  Funds 

(9)  Purchase  Request 

(10)  Customer 

d.  The  Pilot  team  has  applied  the  scoping  criteria,  selected 
functions  according  to  the  scoping  procedures  and  recommends  that 
the  following  functions  (described  in  enclosure  12,  SELECTED 
FUNCTION  REPORT)  be  included  within  the  scope  of  the  Logical 
Functional  Architecture : 

(1)  Purchase  Request  Processing 

(2)  Offer  Evaluation 

( 3 )  Contract  Award 

(4)  Contract  Administration 
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COTRACTOR  PROFILE  PILOT  TEAM  PAGE  4 

SUBJECT:  Memorandum  of  Scoping  for  Logical  Information  Architecture 


( 5 )  Forward  Price  Rate  Development 

( 6 )  Contractor  System  Review 

(7)  Mobilization  Requirement  Determination 

(8)  Industrial  Preparedness  Planning  (IPP)  Candidate  Item 
Evaluation 

(9)  Production  Planning  Schedule  Development 

(10)  IPP  Package  Development 


5.  The  scheduled  date  for  the  completion  of  the  next  phase  of  the 
Logical  Information  Architecture  Development  (i.e.,  Global  Analysis) 
is  30  March  1990. 


Team  Members 

DLA-C  (J.  Faust) 
DLA-?  (J.  Flott ) 
DLA—Q  (D.  Fuller) 
DLA-Q  (?.  Wells) 


Francis  C.  Bruno 
Team  Leader 
DLA-AP 


Figure  1 .4.7—7  Subject  Area  Scope  IOM 


127 


1.4  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 

1.4  PREPARE  SCOPE  MEMORANDUM 

There  are  no  IEW  procedures  for  this  section. 
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1.4  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 
1.4  PREPARE  SCOPE  MEMORANDUM 

There  are  no  PC  Dictionary  procedures  for  this  section. 
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2  GLOBAL  ANALYSIS 


In  this  phase  the  global  Functional  and  Data  Architectures  are 
developed  "vertically"  in  more  depth.  The  functions  which  were 
selected  in  the  scoping  phase  are  decomposed  into  processes  and  the 
selected  entities  are  decomposed  into  subentities  and  attributes. 
These  two  architectures  are  "mapped"  together  at  all  levels  of  the 
decomposition.  Additionally,  the  processes  are  related  together 
according  to  their  dependencies  and  sequences  of  occurrence  in  the 
life  cycles  of  the  entities,  (e.g.,  the  life  cycle  of  an  "item"  or 
"contract").  The  scoping  criteria  (i.e.,  Objectives  and  Information 
Requirements)  are  continually  applied  at  each  step  of  Global  Analysis 
and  a  final  Scope  Memorandum  is  prepared  which  explains  what  is  in 
scope,  what  is  out-of-scope,  and  why. 
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2.1  DEVELOP  AND  ATTRIBUTE  THE  ENTITY  RELATIONSHIP  MODEL 


Figure  2.1-1  Step  Overview 
Figure  2.1-2  Step  Products 
Figure  2.1-3  Step  Components 

2.1.1  PURPOSE 

2.1.2  COMPONENTS/TERMS 

2. 1.2.1  Entity 

2. 1.2. 2  Entity  Type 

2. 1.2. 3  Substantive  Entity  Type 

2. 1.2. 4  Substantive  Sub-Entity  Type 

2.1.2. 5  Classifying  Entity  Type 

2. 1.2. 6  Classifying  Sub-Entity  Type 

2. 1.2. 7  Relationship 

2. 1.2. 8  Substantive  Relationship 

2. 1.2. 9  Classifying  Relationship 

2.1.2.10  Entity  Relationship  Diagram  (ERD) 

2.1.2.11  Substantive  ERD 

2.1.2.12  Classifying  ERD 

2.1.2.13  Cardinality 

2.1.2.14  Attribute 

2.1.2.15  Attribute  Value 

2.1.3  INPUT  PRODUCTS 

2. 1.3.1  Conceptual  Entity  Types 

2. 1.3. 2  Scope  Memorandum 

2. 1.3. 3  Relevant  Business  Documents 


2.1.4  GENERAL  PROCEDURES 

2. 1.4.0  DO's  and  DON'Ts 

2. 1.4.1  Study  Conceptual  Entity  Types  and  Scope  Memorandum 

2. 1.4. 2  Develop  Initial  Entity  Relationship  Model 

2. 1.4. 3  Identify  Initial  Set  of  Substantive  Entity  Types 
and  Sub-Types 

2. 1.4. 4  Evaluate  and  Revise  Initial  Set  of  Substantive 
Entity  Types  and  Sub-types 

2. 1.4. 5  Briefly  Define  Each  Substantive  Entity  Type  and 
Sub-type 

2. 1.4. 6  Identify  Substantive  Relationships 

2. 1.4. 7  Develop  Initial  Substantive  ERD 

2. 1.4. 8  Evaluate  and  Revise  Substantive  ERD 

2. 1.4. 9  Define  Substantive  Relationships 

2.1.4.10  Determine  Cardinalities  in  Substantive  ERD 

2.1.4.11  Identify  Classifying  Entity  Types  and  Sub-Entity 
Types  for  each  Substantive  Entity  Type 

2.1.4.12  Develop  Initial  Classifying  ERDs 

2.1.4.13  Define  Each  Classifying  Entity  Type  and  Sub-type 

2.1.4.14  Evaluate  and  Revise  Initial  Classifying  ERDs 

2.1.4.15  Review  and  Revise  Classifying  Entity  Type  and 
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Sub-type 

2.1.4.16  Identify  and  Define  Attributes  for  each  Entity 
Type 

2.1.4.17  Evaluate  Attribute  Assignments  to  Entities 

2.1.5  OUTPUT  PRODUCTS 

2. 1.5.1  Entity  Relationship  Diagrams  (ERD) 

2. 1.5. 2  Entity  Type  Definitions 

2. 1.5. 3  Relationship  Type  Definitions 

2. 1.5.4  Attributed  Entities 

2. 1.5. 5  Attribute  Definitions 

2.1.6  RULES 

2. 1.6.1  Evaluation  of  Substantive  Entity  Types  and 
Sub-Types 

2. 1.6. 2  Evaluation  of  Substantive  ERD 

2. 1.6. 3  Evaluation  of  Classifying  ERD 

2. 1.6. 4  Evaluation  of  Attribute  Assignments  and  Names 

2. 1.6. 5  Confirm  Resolution  of  All  Outstanding  Issues 

2.1.7  EXAMPLES 

Figure  2. 1.7-1  Entity  Relationship  Diagrams  (ERD) 

Figure  2. 1.7-2  Entity  Type  Definitions/Attributed  Entities 
Figure  2. 1.7-3  Attributed  Entities 


2.1  Appendix  A  -  Detailed  IEW  Procedures 

2.1  Appendix  B  -  Detailed  PC  Dictionary  Procedures 
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MURE  IVI 
STEP  OVERVIEW 
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SCOPING 


FUNCTIONAL 

ARCHITECTURE 


MAPS 


OATA 

ARCHITECTURE 


ATTRIBUTE  DEFINITK)  N  REPORT 


SCOPING 


FUNCTIONAL 

ARCHITECTURE 


MAPS 


DATA 

ARCH 


COMPONENTS 


2.1 

DEVELOP  AND 
ATTRIBUTE  THE 
ENTITY 

RELATIONSHIP 

MODEL 

STEPS 


1.  STUDY  CONCEPTUAL  ENTITY  TYPES  AND  SC'.^E  MEMO 

2.  DEVELOP  INITIAL  ENTITY  RELATIONSHIP  MODEL 

3.  IDENTIFY  INITIAL  SET  OF  SU8STANITVE  ENTITY  TYPES 

AND  SUB-TYPES 

4.  EVALUATE  AND  REVISE  INITIAL  SET  OF  SUBSTANTIVE 

ENTITY  TYPES  AND  SUB-TYPES 

5.  BRIEFLY  DEFINE  EACH  SUBSTANTIVE  ENTITY  TYPE  AND 
SUB-TYPE 

6.  IDENTIFY  SUBSTANTIVE  RELATIONSHIPS 

7.  REVISE  INITIAL  SUBSTANTIVE  ERD 

8.  EVALUATE  AND  REVISE  SUBSTANTIVE  ERO 

9.  DEFINE  SUBSTANTIVE  RELATIONSHIPS 

10.  DETERMINE  CARDINALITIES  IN  SUBSTANTIVE  ERD 

11.  IDENTIFY  CLASSIFYING  ENTITY  TYPES  AND  SUB-ENTITY 

TYPES  FOR  EACH  SUBSTANTIVE  ENTITY  TYPE 

12.  DEVELOP  INITIAL  CLASSIFYING  ERO 

13.  DEFINE  EACH  CLASSIFYING  ENTITY  TYPE  AND  SUB-TYPE 

14.  EVALUATE  AND  REVSE  INITIAL  CLASSIFYING  ERD 

IS.  REVIEW  AND  REVBE  CLASSIFYING  ENTTTY  TYPE  ANO 
SUB-TYPE 

IS.  IDENTIFY  ATTRIBUTES  FOR  EACH  ENTITY  TYPE 

17.  EVALUATE  ATTRIBUTE  ASSIGNMENTS  TO  ENTITIES 

FIGURE  2.1-3 
STEP  COMPONENTS 


2.1  DEVELOP  AND  ATTRIBUTE  THE  ENTITY  RELATIONSHIP  MODEL 

2.1.1  PURPOSE 

The  entity  relationship  (E-R)  model  is  a  key  analytical  device  for 
describing  and  understanding  systems  of  any  kind  in  fundamental  terms. 
E-R  modeling  accepts  as  a  fundamental  premise  that  any  system  --  an 
ecosystem,  biological  system,  mechanical  system,  social  system, 
transportation  system,  business  system,  information  system,  etc.  --  can 
be  defined  and  understood  through  the  use  of  two  simple  concepts: 
entities  and  relationships.  All  things,  tangible  and  intangible, 
within  the  scope  of  interest  of  the  system  can  be  thought  of  as 
entities;  and,  in  forming  particular  relationships  which  each  other, 
the  entities  "interact"  to  form  a  system.  Therefore,  in  applying  this 
technique,  we  have  but  two  types  of  objects  to  manipulate:  entity 
types  and  relationship  types. 

In  this  step,  the  E-R  modeling  technique  is  applied  to  the  task  of 
defining  the  DLA  business  system  from  an  information  management 
perspective.  For  instance,  if  an  entity  is  a  person,  place,  thing, 
concept,  or  event  in  which  DLA  has  a  business  interest,  then  having 
information  about  the  entity  is  critical  to  DLA.  The  E-R  modeling 
technique  is  extremely  useful  in  arriving  at  the  correct  logical  design 
of  automated  databases,  fulfilling  an  objective  of  information  systems 
design  to  maximize  the  sharing  of  data  and  to  minimize  data  redundancy 
among  all  information  systems  of  the  organization.  As  a  model  of  a 
logical  database,  the  entity  relationship  model  is  enriched  with 
attributes.  An  attribute  is  a  characteristic  of  an  entity  type  or  a 
relationship  type.  Attributes  become  the  data  elements  of  the 
database;  they  are  defined  in  the  data  dictionary.  Thus,  the 
attributed  E-R  model  provides  the  initial  logical  data  model  for  the 
system,  or  our  first  view  of  the  structure  and  content  of  the  database 
required  by  the  processes  we  want  to  automate. 

In  designing  information  systems,  the  purpose  of  the  attributed  E-R 
model  is  to  provide  a  detailed,  logical  structure  (or  architecture)  of 
the  data  base,  a  structure  which  is:  a)  a  highly  stable 
representation  of  the  data  requirements  of  the  business  system  because 
it  directly  reflects  the  essential  nature  of  the  business;  b)  a 
rigorous  description  from  functional  proponents  of  an  information 
system  of  their  data  base  requirements  which  can  be  tracked 
systematically  to  the  resulting  physical  data  base  design;  c) 
independent  of  any  physical  implementation  of  it,  i.e.,  the  logical 
structure  (model)  is  easily  converted  to  any  custom  developed  or  COTS 
data  base  management  system;  d)  flexible  to  changing  business  needs 
because  it  permits  rapid  determination  of  the  data  needs  of  any 
business  function  and  isolates  the  impact  of  change  to  specific  areas 
of  the  data  base;  and  e)  the  key  to  systems  integration  because  it 
strongly  encourages  the  sharing  of  data  by  any  number  of  different 
business  functions. 
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2.1.2  COMPONENTS/TERMS 


The  following  terms  are  defined  from  an  information  management  and 
information  engineering  perspective. 

2. 1.2.1  Entity:  A  person,  place,  concept,  thing,  or  event  about  which 
the  enterprise  requires  information.  It  is  also  called  entity  instance 
or  entity  occurrence. 

2. 1.2. 2  Entity  Type:  The  collection  of  all  the  entities  to  which  a 
specific  definition,  common  attributes  and  relationships  apply. 

2. 1.2. 3  Substantive  Entity  Type:  An  entity  type  which  is  meaningful 
and  relevant  to  the  enterprise  and  whose  purpose  is  not  to  classify  or 
categorize  any  other  entity  type. 

2. 1.2. 4  Substantive  Sub-Entity  Type:  A  substantive  entity  type 
depends  on  the  existence  of  the  entity  type  to  which  it  is  subordinate. 
Being  subordinate  means  that,  whenever  'A'  equals  the  entity  type  and 

' B '  equals  the  Sub-entity  type,  it  is  always  true  that  'A'  is  composed 
Of  'B'. 


2. 1.2. 5  Classifying  Entity  Type:  An  entity  type  whose  single  purpose 
is  to  classify  or  categorize  substantive  entity  types  or  substantive 
sub-entity  types. 

2. 1.2.6  Classifying  Sub-Entity  Type:  A  classifying  entity  type  which 
depends  on  the  existence  of  a  classifying  entity  type  or  on  another 
classifying  sub-entity  type.  Classifying  sub-entity  types  permit 
unlimited  "levels"  of  hierarchical  classification. 

2. 1.2. 7  Relationship:  A  reason  of  business  relevance  to  the 
enterprise  why  entities  from  one  or  two  entity  types  may  be  associated. 
Relationships  between  entities  of  the  same  entity  type  are  called 
recursive  relationships. 

2. 1.2. 8  Substantive  Relationship:  A  relationship  between  entities  of 
substantive  entity  types  or  between  substantive  sub-entity  types. 

There  can  be  multiple  types  of  relationships  between  the  same  entity 
types. 

2. 1.2. 9  Classifying  Relationship:  A  relationship  between  a 
classifying  entity  type  or  classifying  sub-entity  type  and  any  other 
entity  type. 

2.1.2.10  Entity  Relationship  Diagram  (ERD):  A  diagram,  or  model, 
which  graphically  depicts  all  entity  types,  sub-entity  types,  and 
relationship  types  determined  to  be  within  the  scope  of  the  business 
area  of  interest. 

2.1.2.11  Substantive  ERD:  An  entity  relationship  diagram  (ERD)  which 
contains  only  substantive  objects  (an  object  is  either  an  entity  type 
or  a  relationship  type). 
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2.1.2.12  Classifying  ERD:  An  entity  relationship  diagram  (ERD)  which 
contains  one  substantive  entity  type  only;  all  other  objects  are 
classifying  objects  relevant  to  the  classification  of  the  single 
substantive  entity  type  in  the  ERD. 

2.1.2.13  Cardinality:  The  number  of  pairings  in  which  an  Entity  may 
participate  under  a  Relationship.  Cardinality  occurs  in  five  forms: 
zero-to-one,  one-to-one,  zero-to-many,  one-to-many,  and  many-to-many. 
The  zero-to-one  and  zero-to-many  cardinalities  indicates  that  the 
relationship  between  the  entity  types  is  optional;  for  all  other  case, 
the  cardinality  indicates  that  the  relationship  is  mandatory. 

2.1.2.14  Attribute:  A  type  of  fact  about  an  entity  type  or  sub-entity 
type.  Attributes  are  also  call  data  elements. 

2.1.2.15  Attribute  Value:  A  quantitative  or  descriptive 
characteristic  of  an  entity  (i.e.,  an  instance  of  an  entity  type).  For 
example,  if  "employee  salary"  is  an  attribute,  then  "$400  per  week"  may 
be  the  attribute  value  of  one  of  the  instances  of  an  entity  type  having 
“employee  salary"  as  one  of  its  attributes. 
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2.1.3  INPUT  PRODUCTS 


The  products  which  are  used  as  input  to  the  process  of  developing  and 
attributing  the  entity  relationship  model  are  as  follows. 

2. 1.3.1  Conceptual  Entity  Types:  These  provide  guidance  as  to  broad 
conceptual  business  categories  from  which  entity  types  are  derived. 
Reference  section  1.3  output  products  for  an  example. 

2. 1.3. 2  Scope  Memorandum:  This  provides  the  boundary  of  relevance  for 
the  ERDs.  Reference  section  1.5  output  products  for  an  example. 

2. 1.3. 3  Business  Documents:  These  include  documents  of  various  kinds 
which  can  be  used  as  authoritative  sources  for  identifying  and  defining 
entities,  relationships,  and  attributes.  Examples  are  mission 
statements,  brochures,  pamphlets,  regulations  and  other  policy 
documents,  functional  descriptions  of  existing  information  systems. 
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2.1.4  GENERAL  PROCEDURES 


The  general  sequence  of  tasks  required  to  develop  the  attributed  entity 
relationship  model  are  described  in  order  in  the  following  paragraphs. 
Although  this  is  the  normal  sequence,  it  is  very  important  to  keep  in 
mind  that  this  process  is  iterative  in  nature.  Each  succeeding  step 
usually  reveals  an  oversight  in  a  preceding  step,  and  acts  as  a  natural 
validation  step  even  when  it  is  not  explicitly  intended  for  validation. 
Thus,  a  temporary  return  to  previous  steps  in  altogether  proper  and 
normally  occurs  frequently.  Preceding  the  first  procedural  step  is  a 
paragraph  which  outlines  the  DO's  and  DON'Ts  associated  with  the 
dynamic  process  of  data  modeling. 

2. 1.4.0  DO's  and  DON'Ts 

In  addition  to  the  rules  of  a  technical  nature  provided,  this  section 
provides  guidance  for  managing  the  process  of  developing  the  attributed 
entity  relationship  model  and  ensuring  that  it  is  successfully 
completed.  The  process  has  all  the  challenges  of  any  endeavor 
requiring  cooperation  among  peers  and  is  an  exercise  in  a  group 
dynamics.  Thus,  simply  following  the  technical  rules  of  data  modeling 
is  not  enough  to  ensure  success.  The  following  "do's  and  don'ts", 
derived  from  data  modeling  projects  in  DLA,  should  be  as  carefully 
attended  to  by  data  modeling  project  teams  as  are  the  technical  rules. 

DO  DON'T 

a.  Bring  Management  into  the  a.  Minimize  the  involvement  of 

process  at  the  beginning  and  management  in  the  process, 

periodically  throughout  to  ensure 
their  continuing  support  and 
understanding. 

b.  Obtain  broad  participation  from 
knowledgeable  representatives  of 
each  functional  area  of  the 
organization  expected  to  benefit 
from  the  implemented  system.  Have 
core  team  of  permanent  members, 
supplemented  with  "experts"  brought 
in  when  needed  to  cover  specific 
topics.  Core  team  should  have  3-6 
members,  depending  on  scope  of  the 
model . 

c.  Be  open  minded;  look  for 
insights  into  new  opportunities 
for  improving  the  way  business  is 
done  and  information  is  used. 

d.  Have  an  objective  facilitator 
whose  two  primary  skills  are  data 
modeling  techniques  and  consensus 
building.  Facilitators  should  not 
make  decisions;  they  should  suggest 


b.  Try  to  accomplish  the  data 
model  with  a  narrow  focused 
group  of  too  few  who  will  have 
traditional  biases,  nor  with  too 
many  who  will  slow  the  process  a 
with  unnecessary  "fine  tuning" 
at  every  turn. 


c.  Be  too  wedded  to  the  traditional 
view  of  the  business  or  its  file 
systems. 


d.  Let  one  voice  dominate  discus¬ 
sion  and  decision-making. 
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solutions  and  lead  the  functional 
team  to  making  its  own  decisions. 

e.  Allow  "engineering  license"  in 
the  beginning  of  the  effort  to 
allow  thoughts  to  flow  freely  and 
to  get  "off  the  block".  Insist  on 
rigor  only  after  you  go  into  the 
first  validation  step  of  the  ini¬ 
tial  E-R  model . 


f.  Get  the  facts. 


g.  Table  all  issues  that  are 
discussed  up  to  15  minutes  and 
not  resolved.  Most  of  them  will 
be  quickly  resolved  later  once 
further  insight  about  other 
aspects  of  the  model  is  obtained. 


h.  Review  technical  decisions  of 
previous  day  at  beginning  of  each 
day.  Take  15-20  minutes  to  do 
this.  It  serves  as  a  "warm  start" 
for  a  groggy  group  and  a  good 
transition. 

i.  Take  seriously  the  defining 
of  entity  types,  relationship 
types,  and  attributes.  This  step, 
although  some  think  is  tedious,  is 
essential.  Without  it,  you  have 
only  names  and  diagrams  which, 
however  useful,  are  subject  to 
wide  interpretation.  Only  with 
their  associated  (and  carefully 
defined)  definitions  do  you  bring 
rigor  to  the  model  end  eliminate 
much  room  for  misunderstanding  and 
oversight. 

j.  Keep  clear  view  of  what's  been 
done  to  date,  and  what  is  still 
left  to  do.  The  team  must  know 
specifically  where  it  is  in  the 
process;  besides  the  project 
management  aspect,  this  awareness 
is  important  for  motivation. 


e.  Be  rigid  in  the  beginning  with 
the  strict  rules  of  data  modeling; 
it  will  inhibit  the  process  of  free 
(albeit  facilitated)  thought  needed 
to  bring  a  lot  of  ideas  to  the  table 
to  work  with.  Early  rigidity  will 
slow  the  process  and  diminish  the 
motivation  of  the  functional  repre¬ 
sentatives. 

f.  Base  decisions  on  conjecture  or 
opinion  unless  there  is  no  choice. 

g.  Let  one  issue  drag  on  beyond  15 
minutes;  it  will  usually  be  of  in¬ 
terest  only  to  the  two  people  who 
disagree,  while  everyone  else  wants 
to  proceed;  besides,  experience 
shows  that  90  percent  of  all  issues 
have  obvious  solutions  after  you 
wait  a  day  or  two  and  further  under¬ 
standing  about  other  parts  of  the 
model  is  clear  to  all. 

h.  Go  too  far  without  a  review.  It 
is  important  for  the  group  to  keep 
in  perspective  what  they  are  doing, 
and  not  "lose  the  forest  for  the 
trees." 


i.  Neglect  the  work  of  defining 
the  objects  of  the  model. 


j.  Let  the  process  "swim."  Stay 
very  structured  in  the  day-to-day 
objectives  and  progress,  and  keep 
project  perspective  as  well  as 
technical  perspective. 
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k.  Use  a  CASE  tool  and  keep  its 
database  up  to  date  daily.  It  is 
not  always  required  to  print  out 
its  contents;  in  fact  you  should 
avoid  this  as  paper  copies  are 
very  time  consuming  to  keep  cur¬ 
rent. 

l.  Do  a  comprehensive  review  of 
the  E-R  Model  with  as  many  func¬ 
tional  representatives  who  par¬ 
ticipated  as  possible.  Don't  go 
over  all  the  attributes,  but  do 
go  over  the  ERD  and  the  cardinal¬ 
ities.  Very  important  for  all 

to  come  away  with  a  feeling  that 
they  have  a  good  product.  Invite 
first  line  managers. 


k.  Use  the  CASE  tool  until  you  are 
ready  to  become  technically  struc¬ 
tured,  usually  after  you  have  ob¬ 
tained  reasonable  consensus  on  the 
initial  substantive  ERD  which  you 
have  drawn  on  a  white  board. 


1.  Declare  you're  finished  until 
a  comprehensive  review  of  the  model 
is  done  in  front  of  the  whole  group. 
This  is  best  done  by  the  lead 
facilitator  with  help  from  the  core 
team  members. 


2. 1.4.1  Study  Conceptual  Entity  Types  and  Scope  Memorandum 

The  team  reexamines  and  discusses  the  conceptual  entity  types  from  the 
enterprise  model  and,  as  a  group,  reaffirms  the  scope  of  the  project 
from  both  a  functional  and  data  standpoint.  This  is  simply  a  general 
discussion  to  ensure  there  is  a  common  understanding  of  what  to  include 
and  what  to  exclude.  The  scope  of  the  data  model  can,  in  a 
data-oriented  approach,  be  larger  than  the  functional  scope  but  can 
never  be  less  than  it. 


2. 1.4.2  Develop  Initial  Entity  Relationship  Model 

A  person  or  two  persons  schooled  in  entity  relationship  modeling 
techniques  will  take  one  or  two  days  to  develop  an  initial  E-R  model  to 
be  used  as  a  working  draft.  This  model  is  used  to  brief  the  group 
initially  on  what  the  final  E-R  model  might  look  like.  It  is  not  to  be 
taken  too  seriously  at  this  time;  it  serves  as  a  starting  point  to 
prevent  time  delays  which  often  occur  when  a  larger  gfoup  tries  to 
start  the  initial  model  from  scratch.  It  should  be  briefed  to  the 
whole  team  once,  then  the  team  proceeds  to  the  next  step.  This  is  an 
optional  step.  If  not  done,  simply  go  to  the  next  step. 

2. 1.4. 3  Identify  Initial  Set  of  Substantive  Entity  Types  and  Sub-Types 

Identify  candidate  entity  types  for  the  entire  scope  of  the  business 
area  being  analyzed,  using  as  a  starting  point  the  conceptual  entity 
types  determined  previously  to  be  within  scope.  Do  this  by  focusing  on 
the  primary  sources  of  business  entities:  the  products  of  the  business 
area,  the  resources  required  by  the  business  area  to  produce  its 
products,  the  agents  which  cause  the  generation  of  the  products,  and 
the  customers  of  the  products.  For  each  substantive  entity  type  (which 
should  have  a  meaningful  existence,  independent  of  other  entity  types) 
identify  the  sub-entity  types.  To  do  this,  ask  what  types  of  things  is 
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each  entity  type  composed  of.  Some  entity  types  will  have  no 
sub-entity  types;  instead,  they  will  have  only  attributes.  Attributes 
are  identified  in  a  later  step  of  this  procedure. 

Work  as  a  whole  team  together  on  this  task. 

2. 1.4.4  Evaluate  and  Revise  Initial  Set  of  Substantive  Entity  Types 
and  Sub-types 

Apply  the  rules  presented  below  for  evaluating  substantive  entity  types 
and  sub-entity  types.  Revise  entity  types  and  sub-entity  types  as 
required.  Work  as  a  whole  team  together  on  this  task. 

2. 1.4. 5  Briefly  Define  Each  Substantive  Entity  Type  and  Sub-type 

Write  one  to  three  sentences  of  definition  for  each  substantive  entity 
type  or  sub-entity  type.  Divide  the  objects  and  assign  to  pairs  of 
team  members. 

2. 1.4. 6  Identify  Substantive  Relationships 

Begin  by  constructing  a  matrix  of  all  substantive  entity  types  and 
sub-types  on  both  the  vertical  and  horizontal  axes.  They  are  listed 
down  the  left  side  of  the  matrix  in  the  same  order  as  they  are  listed 
across  the  top.  List  all  sub-entity  types  immediately  after  the  entity 
type  of  which  they  are  subordinate. 

For  each  cell  in  the  matrix,  determine  whether  there  is  a  relationship 
of  relevance  between  the  two  entity  types  which  intersect  there.  If 
there  is,  put  a  number  in  the  cell  and  name  it  by  writing  a  sentence 
with  one  entity  type  as  the  subject  of  the  sentence,  the  other  entity 
type  as  the  object  of  the  sentence,  and  the  relationship  is  the  verb  or 
verb  phrase  of  the  sentence.  These  verb  phases  will  later  be  written 
on  the  ERD  as  the  relationship  name.  Remember,  more  than  one  type  of 
relationship  can  exist  between  the  same  two  entity  types. 

A  couple  of  team  members  can  establish  the  matrix,  then  filling  in  the 
cells  of  a  subset  of  the  matrix  can  be  assigned  to  pairs  of  team 
members  working  simultaneously  with  other  pairs. 

2. 1.4. 7  Revise  Initial  Substantive  ERD 

Here,  the  team  decides  whether  the  initial  ERD  is  worth  revising  or 
that  it  should  simply  start  again  using  the  group  of  sentences  from  the 
previous  step.  In  any  case,  the  sentences  are  the  rigorous  source  for 
the  ERD.  The  team  can  decide  to  break  up  the  entity-entity  matrix  and 
associated  sentences  into  several  subject  area  views  (or  partial  ERDs) 
of  the  global  ERD  to  reduce  complexity.  The  simplest  any  substantive 
ERD  should  be  is:  one  substantive  entity  type,  all  sub-entity  types  for 
that  entity  type,  and  all  other  entity  types  which  have  relationships 
with  the  primary  entity  type  of  the  ERD.  After  deciding  which 
substantive  entity  type  to  make  the  focus  of  the  ERD,  draw  the  ERD, 
naming  all  the  entity  types  and  relationships  on  the  diagram  according 
to  the  naming  conventions.  Do  this  for  each  substantive  entity  type. 
The  whole  team  works  on  this  activity  together. 
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2. 1.4. 8  Evaluate  and  Revise  Substantive  ERD 

Use  the  rules  provided  below  for  evaluating  the  ERD,  and  revise  as 
necessary.  Accomplish  this  activity  as  a  whole  group  together. 

2. 1.4. 9  Define  Substantive  Relationships 

In  one  to  three  sentences,  describe  what  the  relationship  (verb  phrase) 
means  in  relation  to  the  entity  types  it  serves  to  relate.  Divide  this 
activity  among  pairs  of  team  members. 

2.1.4.10  Determine  Cardinalities  in  Substantive  ERD 

Determine  the  cardinalities  of  each  relationship  on  the  ERD.  This  is 
usually  quite  intuitive  by  the  functional  representatives  of  the  team. 
Rarely  does  any  special  research  need  to  be  done. 

The  whole  team  should  work  together  on  this. 

2.1.4.11  Identify  Classifying  Entity  Types  and  Sub-Entity  Types  for 
each  Substantive  Entity  Type 

A  classifying  entity  type  is  the  one  at  the  top  of  a  hierarchy  of  set 
of  classifying  entity  types.  All  entity  types  subordinate  to  the  one 
at  the  top  level  are  the  classifying  sub-entity  types. 

Work  separately  with  each  substantive  entity  type,  classifying  its 
entities  into  smaller  groups.  Think  of  all  the  different  ways  in  which 
the  Entities  might  have  to  be  sorted  for  processing  or  management 
reporting.  For  example,  how  can  all  the  occurrences  of  CARs  be 
grouped?  CARs  can  be  grouped  by  FUEL  SYSTEM,  FUEL  TYPE,  ENGINE  TYPE, 
etc.  The  processing  and/or  reporting  for  FUEL  SYSTEM  information  would 
be  different  from  that  of  ENGINE  TYPE  information.)  In  the  ERD,  add  a 
new  entity  type  with  a  name  that  describes  the  classifying  attribute 
(these  usually  end  with  the  word  TYPE).  Add  the  relationship  from  the 
entity  type  to  the  classifying  entity  type  using  the  relationship  names 
"classif ies/is-classif ied-by"  in  the  proper  order. 

For  each  classifying  entity  type,  add  3  attributes:  the  code,  a  name 
for  the  code  and  text  describing  the  code.  In  a  physical 
implementation,  these  classifying  entity  types  will  more  than  likely 
become  code  tables  in  the  database  design. 

Think  of  all  possible  'kinds-of'  or  'types-of'  that  are  included  within 
the  Entities.  For  each  Classifying  Attribute,  identify  all  of  its 
possible  legal  values.  (E.g.,  What  kinds  or  types  of  CARs  are  in  each 
smaller  group  of  CARs?  The  possible  FUEL  SYSTEMS  of  CARs  would  be  FUEL 
INJECTION  and  CARBURATION;  the  possible  FUEL  TYPEs  of  CARs  would  be 
DIESEL  and  GAS;  the  possible  ENGINE  TYPEs  of  CARs  would  be  ROTARY  and 
PISTON.)  Determine  if  any  of  the  values  need  to  be  furthered  classified 
to  be  meaningful  or  useful  for  the  scope  of  the  project.  (E.g.,  For 
FUEL  INJECTION,  CARBURATION,  DIESEL,  GASOLINE,  ROTARY,  and  PISTON,  do 
we  care  about  any  more  details?)  In  other  words,  do  we  need  to 
identify  a  smaller  population  of  the  larger  population?  If  we  do,  then 
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we  have  identified  a  new  classifying  entity  type  that  has  a 
relationship  to  another  classifying  entity  type. 

Repeat  above  steps  until  the  values  can  not  or  should  not  be  further 
classified,  based  on  the  scoping  criteria  or  exhaustiveness  of  the 
entity  type.  (E.g.,  If  we  do  care  about  more  details,  what  more  do  we 
want  to  know  about  ROTARY  ENGINES,  for  example  NUMBER  OF  ROTORS;  what 
more  do  we  want  to  know  about  GASOLINE  FUEL  TYPES,  for  example  GASOLINE 
GRADES.  Then  identify  the  values  for  each,  for  example  TWO  ROTORS, 
THREE  ROTORS  and  UNLEADED  GASOLINE,  LEADED  GASOLINE.) 

Divide  the  substantive  entity  types  to  be  classified  evenly  among  the 
group,  but  work  in  pairs. 

2.1.4.12  Develop  Initial  Classifying  ERDs 

a)  Create  a  separate  ERD  for  each  substantive  entity  type,  preferably 
with  the  substantive  entity  type  in  the  middle.  The  classifying  and 
sub-entity  types  should  surround  the  substantive  entity  type  with  their 
appropriate  relationships. 

b)  Enter  cardinalities  in  each  ERD.  All  should  be  one-to-many. 

Divide  this  exercise  evenly  among  the  team  members;  however,  working  in 
pairs  is  more  effective  than  working  alone  on  an  ERD. 

2.1.4.13  Define  Each  Classifying  Entity  Type  and  Sub-type 

Write  one  to  three  sentence  descriptions  of  each  classifying  entity 
type  or  sub-entity  type  which  embellishes  the  entity  type  name 
sufficiently  to  understand  what  the  classification  really  means. 

Divide  the  entity  types  and  sub-types  evenly  among  team  members. 

2.1.4.14  Evaluate  and  Revise  Initial  Classifying  ERDs 

Apply  the  rules  for  evaluating  a  classifying  ERD,  and  revise  the  ERD  as 
required.  Do  this  exercise  as  a  whole  group  together. 

2.1.4.15  Review  and  Revise  Classifying  Entity  Type  and  Sub-type 
Definitions 

Revise  the  definitions  in  light  of  all  that  has  been  learned  to  date. 
Often,  the  first  set  of  definitions  prove  inadequate.  With  new 
perspective,  the  analysts  realize  the  shortcomings  and  revise 
accordingly.  Each  team  member  should  examine  all  definitions  and  offer 
comments  to  the  authors. 

2.1.4.16  Identify  and  Define  Attributes  for  each  Entity  Type 

Identify  the  entity  identifier,  the  entity  name,  the  entity 
description,  and  all  other  non-identifier  attributes  that  would  be 
associated  with  the  entity.  Remember,  we  only  want  to  identify  the 
attributes  which  are  relevant,  i.e.,  that  are  within  the  project  scope. 
We  only  want  their  names  for  now.  Enter  all  attributes  of  every  entity 
type,  both  substantive  and  classifying  entity  and  sub-entity  types. 
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Normally,  the  substantive  entity  types  and  sub-entity  types  will  have 
at  least  an  identifying  attribute  and  a  text  attribute  for  a 
description  plus  more,  sometimes  much  more.  Attributes  are 
brainstormed  first,  using  any  name  that  comes  to  mind.  After  a  number 
of  them  are  identified,  the  team  pauses  and  applies  the  naming 
conventions  to  each  attribute  identified.  From  that  point  forward,  any 
additional  attributes  identified  are  added  with  naming  conventions 
followed. 

Alternatively,  the  team  can  begin  its  attribute  identification  exercise 
by  pulling  them  from  existing  file  structures,  data  dictionaries,  or 
from  forms  and  reports  currently  in  use,  still  applying  the  naming 
conventions  as  required. 

Brief  but  meaningful  definitions  for  each  attribute  should  be  done  at 
this  time. 

This  task  should  be  divided  among  team  members,  with  each  member  or 
pair  of  members  responsible  for  defining  a  set  of  attributes  that  seem 
to  be  closely  related. 

2.1.4.17  Evaluate  Attribute  Assignments  to  Entities 

Evaluate  the  correctness  of  assignment  of  attributes  to  entity  types 
accomplished  in  the  previous  step  by  applying  the  rules  for  evaluation 
of  attribute  assignments.  Revise  accordingly. 
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2.1.5  OUTPUT  PRODUCTS 

The  output  products  of  this  step  of  the  methodology  are  listed  below. 

2. 1.5.1  Entity  Relationship  Diagrams  (ERD)  (Figure  2. 1.7-1) 

One  ERD  presents  the  entire  model  showing  all  entity  types  and 
relationship  types,  with  cardinalities.  Also,  each  substantive  entity 
type  is  displayed  as  a  separate  subject  area,  showing  its  relationships 
to  other  entity  types. 

2. 1.5. 2  Entity  Type  Definitions  (Figure  2. 1.7-2) 

2. 1.5. 3  Relationship  Type  Definitions 

2. 1.5. 4  Attributed  Entities  (Figure  2. 1.7-2) 

2. 1.5. 5  Attribute  Definitions  (Figure  2. 1.7-3) 
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2.1.6  RULES 


The  following  rules  are  expressed  as  steps  in  an  evaluation  procedure 
and  are  invoked  by  those  steps  in  the  general  procedure  above  which 
call  for  evaluation.  In  addition  to  being  applied  as  a  formal  step  in 
the  procedure,  the  rules  should  be  applied  dynamically  by  the  team  as 
it  develops  the  different  output  products  named  above. 

2. 1.6.1  Evaluation  of  Substantive  Entity  Types  and  Sub-Types 

a.  Confirm  the  substantive  nature  of  the  entity  types. 

All  entity  types  are  of  two  types,  substantive  and  classifying. 
Substantive  entity  types  are  the  object  of  classification,  but  they 
classify  nothing.  Substantive  entities  are  the  actual  persons,  places, 
concepts,  things,  or  events  which  the  enterprise  needs  in  order  to 
fulfill  its  mission,  regardless  of  how  the  enterprise  wishes  to 
classify  them.  A  substantive  entity  type  cannot  classify  another 
entity  type. 

b.  Confirm  uniqueness  of  each  entity  type. 

For  both  the  substantive  entity  types  and  the  sub-entity  types,  each 
must  be  truly  unique  from  all  others  identified. 

To  be  a  unique  entity  type,  one  must  confirm  that  no  other  entity  type 
in  the  list  of  entity  types  is  likely  to  have  an  identical,  or  nearly 
identical  set  of  attributes.  Even  though  entity  attribution  has  not 
yet  been  done,  the  determination  of  the  likelihood  of  two  entity  types 
having  nearly  identical  attributes  is  ascertained  intuitively  at  this 
stage.  Intuition  is  proved  right  or  wrong  during  the  rigorous 
attribution  stage.  Remember,  just  because  two  entities  can  be 
classified  differently  does  not  necessarily  mean  the  two  entities  are 
of  different  entity  types  as  well.  For  example,  the  entity  type 
CUSTOMER  could  be  divided  into  two  entity  types:  FEMALE  CUSTOMER  and 
MALE  CUSTOMER.  This  would  be  perfectly  alright  if  there  were  different 
kinds  of  data  kept  about  female  customers  than  was  kept  about  male 
customers.  But  if  the  same  kind  of  information  is  kept  about  both, 
then  one  entity  type,  CUSTOMER,  is  sufficient.  If  the  enterprise 
wishes,  for  example,  to  keep  statistics  on  the  buying  profile  of  its 
male  customers  versus  its  female  customers,  this  would  not  affect  the 
entity  type  CUSTOMER,  but  it  would  generate  the  need  for  a  classifying 
entity  type  called  CUSTOMER  SEX.  Thus,  instead  of  having  two 
substantive  entity  types  called  FEMALE  CUSTOMER  and  MALE  CUSTOMER,  we 
have  one  substantive  entity  type  called  CUSTOMER,  and  one  classifying 
entity  type  called  CUSTOMER  SEX. 

c.  Confirm  sufficiency  of  Sub-entity  types. 

Substantive  sub-entity  types  are  legitimate  if:  the  substantive  entity 
type  is  composed  of  the  substantive  sub-entity  type,  and  more  than  one 
substantive  sub-entity  (instance)  can  exist  for  the  same  substantive 
entity  (instance). 

2. 1.6. 2  Evaluation  of  Substantive  ERD 


148 


a.  Ensure  all  relationship  identified  in  the  entity/entity  matrix  have 
been  captured  in  the  subject  area  ERDs  and  the  global  ERD.  Every 
entity  type  must  participate  in  at  least  one  relationship  with  another 
entity  type. 

b.  Confirm  absence  of  all  redundant  relationship  types. 

A  redundant  relationship  type  is  one  which  associates  two  entity  types 
directly  which  are  already  associated  indirectly  through  mandatory 
relationships  they  have  with  a  common  (third)  entity  type.  Thus,  if 
entity  type  A  is  related  to  entity  type  B,  and  entity  type  B  is  in  turn 
related  to  entity  type  C,  then  if  a  conceptual  relationship  exists 
between  A  and  C  because  of  A's  relationship  to  B,  then  the  ERD  need  not 
show  a  direct  relationship  between  A  and  C,  since  it  already  exists 
through  their  mutual  relationship  to  B. 

c.  Ensure  naming  conventions  for  entity  types  and  relationship  types 
are  followed. 

2. 1.6. 3  Evaluation  of  Classifying  ERD 

a.  Ensure  only  the  lowest  level  of  classifying  entity  in  a  hierarchy 
of  classifying  entity  types  forms  a  relationship  with  a  substantive 
entity  type. 

b.  Not  all  substantive  entities  need  to  be  classified,  i.e.,  form 
relationships  with  classifying  entity  types.  Should  there  be  certain 
substantive  entity  types  which  have  not  been  "classified"  at  all,  ask 
once  more  if  there  is  a  business  need  to  classify  the  substantive 
entity  type. 

c.  Confirm  that  the  classifying  entity  type  forms  the  relationship 
with  the  right  substantive  entity  type  and  not  its  associated 
substantive  sub-entity  type,  or  vice-versa. 

d.  Re-examine  the  cardinalities  of  every  relationship  and  confirm 
their  correctness. 

e.  Legal  Values 

Do  not  identify  the  currently  used  codes  for  a  classifying  attribute; 
instead  identify  the  English  name  of  each  legal  value,  as  used  within 
DLA,  its  clients,  or  its  contractors. 

f.  Why  Classify? 

There  must  be  a  business  reason  which  justifies  classification  that  a) 
falls  within  the  scope  for  classifying  the  Conceptual  Entity  Type,  and 
b)  is  based  on  management  reporting  or  control  processing. 

g.  When  to  Further  Classify 

To  determine  if  a  Legal  Value  can  be  further  classified,  examine  the 
existing  documentation  to  ascertain  if  the  legal  value  names  are  used 
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alone,  or  are  always  used  in  conjunction  with  one  or  more  other  names. 
In  other  words,  ask  if  the  legal  value  name  must  be  qualified  by  some 
other  name(s)  to  be  meaningful  or  useful.  If  so,  it  probably  requires 
further  sub-classifying. 

h.  When  to  Stop  Classifying 

Not  all  legal  values  can  or  should  be  further  classified.  Of  those 
that  are,  not  all  are  classified  the  same  number  of  times.  Do  not  even 
attempt  to  classify  to  the  same  degree.  Stop  trying  to  sub-classify 
whenever  the  result  provides  no  additional  added  value  from  a  business 
standpoint.  Also,  any  candidate  classifying  entity  type  which  has  only 
two  possible  instances  which  translate  to  "on/off"  or  "yes/no"  should 
be  converted  to  classifying  attributes  within  the  substantive  entity 
type  they  classify. 

i.  Mutual  Exclusivity 

Every  legal  value  within  a  set  of  attribute  values  for  the  identifier 
of  a  given  classifying  entity  type  must  be  mutually  exclusive. 

j.  Exhaustiveness 

The  total  legal  values  in  a  set  must  be  exhaustive.  Attempt  to 
completely  exhaust/define  the  classifying  entity  type  by  identifying 
all  of  the  legal  values  of  its  identifier  key. 

k.  Ensure  naming  conventions  for  entity  types  and  relationship  types 
are  followed. 

2. 1.6. 4  Evaluation  of  Attribute  Assignments  and  Names 

a.  Confirm  existence  of  identifying  (key)  attributes  in  each  entity 
type  of  all  kinds  (substantive,  classifying,  and  all  types  of 
sub-entities). 

b.  Confirm  absence  of  all  other  "keys"  but  the  identifying  attributes 
for  any  entity  type. 

c.  Confirm  that  the  identifying  attribute  of  any  kind  of  sub-entity 
type  contains  the  identifying  attribute  of  its  "parent"  entity  type. 

d.  Multi-valued  Attributes:  An  attribute  may  have  only  one  value  at  a 
time.  However,  when  more  than  one  value  of  an  attribute  can  describe 
an  entity  at  the  same  time,  the  attribute  is  said  to  be  multi-valued. 

For  example,  an  E-R  model  may  contain  information  on  the  languages  an 
employee  speaks.  If  J.  Doe  speaks  French,  German,  and  Spanish,  these 
are  different  values  for  the  attribute  Language  Spoken.  In  such  case, 
the  original  attribute  Language  Spoken  must  be  converted  to  an  entity 
type.  The  new  entity  type  includes  French,  German  and  Spanish  as 
entities. 
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e.  Functional  Dependency:  By  definition,  an  attribute  is  a  fact  about 
an  entity  type.  One  attribute,  therefore  cannot  describe  another.  If 
an  attribute  appears  to  do  so,  it  must  be  redefined  as  an  entity  type. 

For  example,  consider  the  previous  example  again.  Language  Spoken  is 
an  attribute  of  EMPLOYEE,  and  it  is  necessary  to  record  the  degree  of 
fluency  and  college  experience  in  each  language.  Degree  of  Fluency  and 
College  Experience  in  a  language  are  attributes  that  describe  the 
attribute  Language  Spoken,  not  the  entity  type  EMPLOYEE. 

Because  the  rules  do  not  permit  on  attribute  to  describe  another, 
LANGUAGE  SPOKEN  must  be  redefined  as  an  entity  type  including  Degree  of 
Fluency  and  College  Experience  among  its  attributes. 

f.  An  attribute  may  describe  only  one  entity  type.  If  an  attribute 
appears  to  describe  two  entity  types,  a  relationship  associates  the 
entity  types  and  the  attribute  belongs  with  the  relationship 
(associative  entity  type). 

g.  Classifying  entities  have  only  three  attributes:  entity  identifier, 
name,  and  description.  Include  a  fourth  --  effective  date  --  if 
necessary. 

2. 1.6. 5  Confirm  Resolution  of  All  Outstanding  Issues 

Ensure  that  all  issues  recorded  during  any  activity  of  the  modeling 
exercise  have  been  answered,  and  the  answer  incorporated  into  the 
model,  if  required. 
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2.1.7  EXAMPLES 

Figure  2. 1.7-1  Entity  Relationship  Diagrams  (ERD) 

Figure  2. 1.7-2  Entity  Type  Definitions/Attribute  Definitions 
Figure  2. 1.7-3  Attributed  Entities 
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Figure  2. 1.7-1  Subject  Area  Kntity  Relat  ionsli  ip  Diagram 
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2.1  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 

2.1  DEVELOP  AND  ATTRIBUTE  THE  ENTITY  RELATIONSHIP  MODEL 

2.1.1  PURPOSE 

2.1.2  COMPONENTS/TERMS 

2.1.3  INPUT  PRODUCTS 

2.1.4  GENERAL  PROCEDURES 

2. 1.4.1  STUDY  CONCEPTUAL  ENTITIES  AND  SCOPE  MEMORANDUM 

2. 1.4. 1.1  LOGON  TO  PLANNING  WORKBENCH 

2. 1.4. 1.2  SELECT  "ENCYCLOPEDIA  LIST"  FUNCTION 

2. 1.4. 1.3  IDENTIFY  CURRENT  ENCYCLOPEDIA  AND  OPEN  BY: 

2. 1.4. 1.3.1  SELECTING  THE  ENCYCLOPEDIA'S  NAME  FROM  THE  LIST 

2. 1.4. 1.3. 2  PULLING  DOWN  THE  "EDIT"  MENU 

2. 1.4. 1.3. 3  SELECTING  THE  "OPEN"  OPTION  FROM  THE  "EDIT"  MENU 

2. 1.4. 1.3. 4  CLOSE  THE  "ENCYCLOPEDIA  LIST"  WINDOW 

2. 1.4. 1.4  PULL  DOWN  THE  "DISPLAY"  MENU 

2. 1.4. 1.5  SELECT  "THE  ENTITY  MODEL"  (SEE  FIGURE  A. 2. 1.1) 

2. 1.4. 1.6  SELECT  "THE  ENTITY  MODEL"  AND  SELECT  "PROCEED" 

2. 1.4. 2  DEVELOP  INITIAL  ENTITY  RELATIONSHIP  MODEL 

2. 1.4. 2.1  PERFORM  STEPS  IN  2. 1.4.1 

2. 1.4. 2. 2  TO  ADD  AN  ENTITY: 

2. 1.4. 2. 2.1  PULL  DOWN  THE  "ADD"  MENU 

2. 1.4. 2. 2. 2  ENTER  NAME  OF  NEW  ENTITY  AND  SELECT  "ENTITY"  AND 
"FUNDAMENTAL"  BLOCKS  AND  SELECT  "PROCEED" 

2. 1.4. 2. 3  TO  ADD  A  RELATIONSHIP 

2. 1.4. 2. 3.1  ENSURE  THAT  BOTH  ENTITIES  TO  BE  INVOLVED  IN  THE 
NEW  RELATIONSHIP  ARE  NOT  CURRENTLY  SELECTED 

2. 1.4. 2. 3. 2  CLICK  THE  MOUSE  DOWN  ON  THE  SOURCE  ENTITY  (THE 
'FROM'  ENTITY)  AND,  KEEPING  THE  BUTTON  DOWN,  DRAG  THE 
CURSOR  ACROSS  THE  SCREEN  TO  THE  TARGET  ENTITY  (THE  'TO' 
ENTITY).  RELEASE  THE  BUTTON  WHEN  THE  CURSOR  RESIDES  IN  THE 
TARGET  ENTITY. 

2. 1.4. 2. 3. 3  ENTER  BOTH  THE  'TO'  NAME  OF  THE  RELATIONSHIP  AND 

THE  'FROM'  NAME  OF  THE  RELATIONSHIP,  AND  SELECT  "PROCEED" 

2. 1.4. 3  IDENTIFY  INITIAL  SET  OF  SUBSTANTIVE  FNTITY  TYPES  AND  SUB-TYPES 

2. 1.4. 3.1  PERFORM  STEPS  IN  2. 1.4. 2 

2. 1.4. 4  EVALUATE  AND  REVISE  INITIAL  SET  OF  SUBSTANTIVE  ENTITY 
TYPES  AND  SUB-TYPES 
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2. 1.4. 4.1  PERFORM  STEPS  IN  2. 1.4. 2 

2. 1.4. 4. 2  TO  DELETE  AN  ENTITY: 

2. 1.4. 4. 2.1  SELECT  THE  ENTITY  (AND  ONLY  THE  ENTITY)  YOU  WISH 
TO  DELETE 

2. 1.4. 4. 2. 2  PULL  DOWN  THE  “EDIT"  MENU 

2. 1.4. 4. 2. 3  SELECT  THE  "DELETE"  FUNCTION 

2. 1.4. 4. 2. 4  SELECT  "PROCEED" 

2. 1.4. 4. 3  TO  DELETE  A  RELATIONSHIP: 

2. 1.4. 4. 3.1  ENSURE  THAT  THE  RELATIONSHIP  HANDLES  ARE  SHOWN: 

2. 1.4. 4. 3. 1.1  PULL  DOWN  THE  "ENTITY  DIAGRAM"  MENU 

2. 1.4. 4. 3. 1.2  SELECT  THE  "SHOW  HANDLES"  FUNCTION  IF  AVAILABLE 

2. 1.4. 4. 3. 2  SELECT  THE  RELATIONSHIP  (AND  ONLY  THE  RELATIONSHIP)  YOU 
WISH  TO  DELETE  BY  CLICKING  ON  ITS  HANDLE 

2. 1.4. 4. 3. 3  PULL  DOWN  THE  "EDIT"  MENU 

2. 1.4. 4. 3. 4  SELECT  THE  "DELETE"  FUNCTION 

2. 1.4. 4. 3. 5  SELECT  "PROCEED" 

2. 1.4.5  BRIEFLY  DEFINE  EACH  SUBSTANTIVE  ENTITY  TYPE  AND  SUB-TYPE 

2. 1.4. 5.1  PERFORM  STEPS  IN  2. 1.4.1 

2. 1.4. 5. 2  DESELECT  ANY  SELECTED  ENTITIES  BY: 

2. 1.4. 5. 2.1  PULLING  DOWN  THE  "SELECT"  MENU 

2. 1.4. 5.2.2  SELECTING  THE  "DESELECT  ALL"  FUNCTION 

2. 1.4. 5. 3  SELECT  THE  ENTITY  WHOSE  DESCRIPTION  YOU  WOULD  LIKE  TO 
ADD  OR  MODIFY 

2. 1.4. 5. 4  P'JLL  DOWN  THE  "DISPLAY"  MENU 

2. 1.4. 5. 5  SELECT  THE  "DETAILS"  FUNCTION 

2. 1.4. 5. 6  USING  THE  ARROW  KEYS  AND  THE  MOUSE,  POSITION  THE  CURSOR 
WITHIN  THE  DESCRIPTION  FIELD  AND  ENTER  ADDITIONS/CHANGES 

2. 1.4. 5. 7  TO  SAVE  THE  NEW  DESCRIPTION: 

2. 1.4. 5. 7.1  PULL  DOWN  THE  "EDIT"  MENU 

2. 1.4. 5. 7. 2  SELECT  THE  "SAVE  AND  CLOSE"  FUNCTION 

2. 1.4. 6  IDENTIFY  SUBSTANTIVE  RELATIONSHIPS 

2. 1.4. 6.1  PERFORM  STEPS  IN  2. 1.4.1 

2. 1.4. 6. 2  PERFORM  STEPS  IN  2. 1.4. 2. 3 

2. 1.4. 6. 3  TO  FURTHER  DESCRIBE  A  RELATIONSHIP: 

2. 1.4. 6. 3.1  SELECT  THE  DESIRED  RELATIONSHIP  AS  DESCRIBED  IN 

2. 1.4. 4. 2.1  AND  2. 1.4. 4. 3. 2 

2. 1.4. 6. 4  PULL  DOWN  THE  "DISPLAY"  MENU 

2. 1.4. 6. 5  SELECT  THE  "DETAILS"  FUNCTION 

2. 1.4. 6. 6  USING  THE  ARROW  KEYS  AND  THE  MOUSE,  POSITION  THE 
CURSOR  WITHIN  THE  'DESCRIPTION'  BLOCK. 

2. 1.4. 6. 7  ENTER  THE  DESCRIPTIVE  INFORMATION. 
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2. 1.4. 6. 8  PULL  DOWN  THE  "EDIT"  MENU 

2. 1.4. 6. 9  SELECT  THE  "SAVE  AND  CLOSE"  FUNCTION 

2. 1.4. 7  DEVELOP  INITIAL  SUBSTANTIVE  ERD 

2. 1.4. 7.1  PERFORM  STEPS  DETAILED  IN  2. 1.4.1,  2. 1.4. 2,  2. 1.4. 4, 

2. 1.4. 5  AND  2. 1.4. 6 

2. 1.4. 8  EVALUATE  AND  REVISE  SUBSTANTIVE  ERD 

2. 1.4. 8.1  PERFORM  STEPS  DETAILED  IN  2. 1.4.1,  2. 1.4. 2,  2. 1.4. 4, 

2. 1.4. 5  AND  2. 1.4. 6 

2. 1.4. 9  DEFINE  SUBSTANTIVE  RELATIONSHIPS 

2. 1.4. 9.1  PERFORM  STEPS  IN  2. 1.4.1,  2. 1.4.2,  2. 1.4. 4,  AND  2. 1.4. 6 

2.1.4.10  DETERMINE  CARDINALITIES  IN  SUBSTANTIVE  ERD 

2.1.4.10.1  PERFORM  STEPS  AS  DETAILED  IN  2. 1.4. 6 

2.1.4.10.2  WHILE  IN  THE  "DETAILS"  FUNCTION,  ENTER  THE  CARDINAL 
RELATIONSHIPS  IN  THE  RESERVED  AREAS  (‘MIN’  AND  'MAX') 

2.1.4.10.3  "SAVE  AND  CLOSE"  AS  DESCRIBED 

2.1.4.11  IDENTIFY  CLASSIFYING  ENTITY  TYPES  AND  SUB-ENTITY  TYPES 
FOR  EACH  SUBSTANTIVE  ENTITY  TYPE 

2.1.4.11.1  LOGON  TO  ANALYSIS  WORKBENCH 

2.1.4.11.2  PULL  DOWN  THE  "DISPLAY'’  MENU 

2.1.4.11.3  SELECT  THE  "DECOMPOSITION  DIAGRAM"  FUNCTION  (SEE  FIGURE 
A. 2. 1 .2) 

2.1.4.11.4  SELECT  "SUBJECT  AREA"  OPTION 

2.1.4.11.5  ENTER  THE  NAME  OF  ONE  FULL  SUBSTANTIVE  CONCEPTUAL 

ENTITY  IF  SUBJECT  AREA  FOR  THAT  ENTITY  NOT  ALREADY  CREATED, 
OTHERWISE  SEE  NEXT  STEP 

2.1.4.11.6  SELECT  "CREATE"  IF  NAME  WAS  ENTERED  OR  "FIND"  IF  NOT. 

IF  USING  "CREATE",  SKIP  NEXT  STEP 

2.1.4.11.7  SELECT  THE  SINGLE  FULL  SUBSTANTIVE  CONCEPTUAL  ENTITY 

FOR  WHICH  YOU  DESIRE  TO  IDENTIFY  CLASSIFYING  AND  SUB-ENTITY 
TYPES,  AND  THEN  SELECT  "PROCEED" 

2.1.4.11.8  ENSURE  THAT  A  SUBJECT  AREA  EXISTS  WHOSE  NAME  EQUALS 
THE  NAME  OF  THE  SPECIFIED  CONCEPTUAL  ENTITY. 

2.1.4.11.9  TO  AOD  A  SUBJECT  AREA: 

2.1.4.11.9.1  PULL  DOWN  THE  "ADD"  MENU 

2.1.4.11.9.2  SELECT  THE  "SUBJECT  AREA"  OPTION 

2.1.4.11.9.3  TYPE  IN  THE  NAME  OF  THE  SUBJECT  AREA  AND  SELECT  "PROCEED" 

2.1.4.11.10  ENSURE  THAT  A  SUBJECT  AREA  EXISTS  WHOSE  NAME  EQUALS 
THE  NAME  OF  THE  SPECIFIED  CONCEPTUAL  ENTITY  FOLLOWED  BY 
THE  EXTENSION,  "-ROOT". 

2.1.4.11.11  ENSURE  THAT  THE  SUBJECT  AREA,  <entity  name>-ROOT  IS 
HIERARCHICALLY  BENEATH  THE  SUBJECT  AREA  FOR  THE  ENTITY 
ITSELF 

2.1.4.11.12  TO  SPECIFY  A  HIERARCHY: 
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2.1.4.11.12.1  ENSURE  THAT  NEITHER  SUBJECT  AREA  IS  SELECTED 

2.1.4.11.12.2  CLICK  THE  CURSOR  ONTO  THE  HIGHER  LEVEL  SUBJECT 

AREA  AND,  KEEPING  THE  BUTTON  DOWN,  DIRECT  THE  CURSOR  TO 
WITHIN  THE  LOWER  LEVEL  SUBJECT  AREA,  AND  RELEASE  THE 
BUTTON. 


2.1.4.11.13 


2.1.4.11.14 

2.1.4.11.15 

2.1.4.11.16 

2.1.4.11.17 


2.1.4.11.18 

2.1.4.11.19 


2.1.4.11.20 


2.1.4.11.21 


2.1.4.11.23 


CREATE  A  SUBJECT  AREA  FOR  EACH  CLASSIFYING  ENTITY 
WHICH  CLASSIFIES  THE  SELECTED  ENTITY  AND  FOR  EACH 
SUB-ENTITY  OF  THE  ENTITY 

PLACE  EACH  SUBJECT  AREA  CREATED  DIRECTLY  BELOW  THE 

ENTITY  SUBJECT  AREA  IN  THE  HIERARCHY 

ONE  AT  A  TIME,  SELECT  EACH  SUBORDINATE  SUBJECT  AREA. 

PULL  DOWN  THE  DISPLAY  MENU 

SELECT  THE  "ENTITY  VIEW"  FUNCTION,  WHICH  WILL 

DISPLAY  AN  ENTITY  DIAGRAM  WHICH  REPRESENTS  A  SUBSET  OF  THE 

ENTIRE  ENTITY  DIAGRAM  (SEE  FIGURE  A. 2. 1.3) 

PULL  DOWN  THE  "ADD"  MENU,  SELECT  "ENTITY"  AND  "FIND" 

IF  "FIND"  WAS  USED  AND  THE  ENTITY  THAT  THE  GIVEN 
SUBJECT  AREA  VIEWS  IS  FOUND,  SELECT  IT  AND  "PROCEED",  ELSE 
"CANCEL",  ENTER  THE  NAME  OF  THE  ENTITY,  AND  SELECT 
"CREATE " 

IF  "CREATE"  WAS  USED,  SELECT  "FUNDAMENTAL"  AND  FILL 
OUT  WHAT  YOU  KNOW  IN  THE  "DESCRIPTION"  BLOCK,  AND  THEN 
"PROCEED" 

EACH  LOWER  LEVEL  SUBJECT  AREA'S  VIEW  SHOULD  INCLUDE 
THE  PARENT  ENTITY  AND  THE  ENTITY  FOR  WHICH  THE  SUBJECT 
AREA  IS  NAMED.  THE  ONE  EXCEPTION  IS  THE  <entity 
name>-RQOT  SUBJECT  AREA,  WHOSE  VIEW  SHOULD  BE  LIMITED  TO 
THE  TOP  LEVEL  ENTITY  (<entity  name>)  BY  ITSELF. 

2.1.4.11.22  IF,  AFTER  PLACING  THE  APPROPRIATE  ENTITIES, 
SUB-ENTITIES,  AND/OR  CLASSIFYING  ENTITIES  INTO  THE  DIAGRAM, 
NO  RELATIONSHIP  IS  SHOWN  BETWEEN  THEM,  CREATE  RELATIONSHIPS 
AS  EXPLAINED  IN  2. 1.4. 2,  2. 1.4. 6,  AND  2.1.4.10. 

AFTER  ALL  OF  THE  FIRST  LEVEL  CLASSIFYING  AND 
SUB-ENTITY  SUBJECT  AREAS  AND  THEIR  RESPECTIVE  ENTITIES  HAVE 
BEEN  DEFINED,  CONTINUE  ON  TO  THE  NEXT  LEVEL  (IF 
NECESSARY)  FOR  EACH,  OBSERVING  THE  SAME  PROCEDURES,  BUT 
WITH  THE  FOLLOWING  ADDITIONAL  RULES: 


2.1.4.11.23.1  ALL  'ANCESTORS'  SHOULD  SHOW  UP  IN  EACH  ENTITY  VIEW 


2.1.4.11.24  CLOSE  EACH  ENTITY  VIEW  BEFORE  PROCEEDING  TO  THE  NEXT  VIA 
THE  SUBJECT  AREA  DECOMPOSITION  DIAGRAM 

2.1.4.11.25  TO  COMBINE  THE  VIEWS  OF  THE  LOWER  LEVEL  SUBJECT  AREAS  INTO 
A  HIGHER  LEVEL  SUBJECT  AREA:  (SEE  FIGURE  A. 2. 1.5) 


2.1.4.11.25.1 

2.1.4.11.25.2 

2.1.4.11.25.3 

2.1.4.11.25.4 

2.1.4.11.25.5 

2.1.4.11.25.6 


IN  THE  SUBJECT  AREA  DECOMPOSITION  DIAGRAM,  DESELECT  ALL 

FOR  EACH  SUBJECT  AREA  WITH  DESCENDENTS,  STARTING 

WITH  THE  LOWER  LEVELS,  SELECT  EACH  DESCENDENT 

PULL  DOWN  THE  "01  SPLAY"  MENU 

SELECT  THE  "COMBINED  VIEWS"  FUNCTION 

ENTER  THE  PARENT  SUBJECT  AREA  NAME  AND  SELECT  "PROCEED" 

AN  ENTITY  VIEW  WILL  BE  DISPLAYED  WHICH  REPRESENTS  THE 

VIEW  OF  THE  ERD  FROM  THE  IDENTIFIED  PARENT  SUBJECT  AREA, 

AND  WHICH  INCLUDES  THE  VIEWS  OF  ALL  OF  THE  IDENTIFIED 
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DESCENOENTS. 


2.1.4.11.26  PERFORM  THE  PREVIOUS  STEPS  FOR  EACH  PARENT  SUBJECT  AREA, 
ONE  AT  A  TIME,  STARTING  AT  THE  BOTTOM  OF  THE  SUBJECT  AREA 
H I ERARCHY 

2.1.4.11.27  CLOSE  THE  SUBJECT  AREA  DECOMPOSITION  DIAGRAM  AND 
CONTINUE  ON  THE  NEXT  TOP  LEVEL  FULL  CONCEPTUAL  SUBSTANTIVE 
ENTITY  AND  PROCEED  IN  THE  SAME  MANNER. 

2.1.4.11.28  AFTER  COMPLETION  OF  ALL  OF  THE  SUBJECT  AREA  VIEWS  FOR  ALL 
OF  THE  ENTITIES,  PERFORM  STEPS  2. 1.4.1  (BUT  IN  ANALYSIS 
WORKBENCH)  IN  ORDER  TO  VIEW  THE  ENTIRE  ERD 

2.1.4.12  DEVELOP  INITIAL  CLASSIFYING  ERDs 

2.1.4.12.1  PERFORM  STEPS  OUTLINED  IN  2.1.4.11  TO  AS  GREAT  A  DETAIL  AS 

IS  REQUIRED.  REMEMBER  TO  PERFORM  THE  COMBINED  VIEWS 

FUNCTION  AT  THE  END  OF  EACH  SESSION. 

2.1.4.13  DEFINE  EACH  CLASSIFYING  ENTITY  TYPE  AND  SUB-TYPE 

2.1.4.13.1  PERFORM  STEPS  OUTLINED  IN  2. 1.4.1,  IN  THE  ANALYSIS 

WORKBENCH,  IN  ORDER  TO  DISPLAY  THE  ENTIRE  ENTITY 

RELATIONSHIP  DIAGRAM 

2.1.4.13.2  PERFORM  STEPS  OUTLINED  IN  2. 1.4. 5  IN  ORDER  TO  ENTER 

THE  DEFINITIONS  FOR  EACH  CLASSIFYING  ENTITY  AND  SUB-TYPE 

2.1.4.14  EVALUATE  AND  REVISE  INITIAL  CLASSIFYING  ERDs 

2.1.4.14.1  REVISE  ENTITY  RELATIONSHIP  DIAGRAM  AS  NECESSARY,  IN 
ACCORDANCE  TO  THE  DEFINED  RULES,  BUT  THROUGH  THE  SUBJECT 
AREA  VIEWS,  AS  DESCRIBED  IN  2.1.4.11 

2.1.4.14.2  REMEMBER  TO  PERFORM  THE  COMBINED  VIEWS  AS  DESCRIBED 
BEFORE  THE  END  OF  THE  SESSION 

2.1.4.15  REVIEW  AND  REVISE  CLASSIFYING  ENTITY  TYPE  AND  SUB-TYPE 
DEFINITIONS 

2.1.4.15.1  MODIFY  CLASSIFYING  ENTITY  TYPE  AND  SUB-TYPE  DEFINITIONS  AS 
NECESSARY  USING  THE  STEPS  PREVIOUSLY  OUTLINED 

2.1.4.16  IDENTIFY  ATTRIBUTES  FOR  EACH  ENTITY  TYPE  AND  ASSOCIATIVE 
ENTITY  TYPE 

2.1.4.16.1  PERFORM  THE  ATTRIBUTION  OF  ENTITIES  ONLY  THROUGH  THE 
SUBJECT  AREA  ENTITY  VIEWS 

2.1.4.16.2  PERFORM  THE  FOLLOWING  STEPS  FOR  EACH  TOP  LEVEL 
CONCEPTUAL  SUBSTANTIVE  ENTITY  IN  TURN 

2.1.4.16.3  BRING  UP  THE  SUBJECT  AREA  DECOMPOSITION  DIAGRAM  FOR 
THE  ENTITY  AS  DESCRIBED  IN  2.1.4.11 

2.1.4.16.4  EACH  ENTITY  WILL  BE  ATTRIBUTED  THROUGH  THE  SUBJECT 
AREA  ENTITY  VIEW  OF  THE  SUBJECT  AREA  WITH  THE  SAME  NAME. 

THE  ENTITY  ITSELF  WILL  BE  ATTRIBUTED  THROUGH  THE 
<entity-name>-ROOT  SUBJECT  AREA.  ON  SUBJECT  AREA  ENTITY 
VIEWS  WITH  A  VIEW  OF  MORE  THAN  ONE  ENTITY  OBJECT,  ATTRIBUTE 
ONLY  THE  ENTITY  OBJECT  WITH  THE  SAME  NAME  AS  THE  SUBJECT 
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2.1.4.16. 

2.1.4.16. 

2.1.4.16. 

2.1.4.16. 

2.1.4.16. 

2.1.4.16. 

2.1.4.16. 

2.1.4.16. 

2.1.4.16. 


2.1.4.16. 

2.1.4.16. 


2.1.4.16. 


2.1.4.17 

2.1.4.17. 

2.1.4.17. 

2.1.4.17. 


2.1.4.17. 

2.1.4.17. 

2.1.4.17. 

2.1.4.17. 


AREA 

5  TO  ATTRIBUTE  AN  ENTITY  OBJECT  (SEE  FIGURE  A. 2. 1.4) 

5.1  ON  THE  APPROPRIATE  SUBJECT  AREA  ENTITY  VIEW,  DESELECT  ALL 

5.2  SELECT  THE  ENTITY  OBJECT  TO  BE  ATTRIBUTED 

5.3  PULL  DOWN  THE  "DISPLAY"  MENU 

5.4  SELECT  THE  "ENTITY  TYPE  DESCRIPTION"  FUNCTION 

5.5  PULL  DOWN  THE  "ADD"  MENU 

5.6  SELECT  THE  "ATTRIBUTE  TYPE"  OPTION 

5.7  SELECT  THE  "FIND"  OPTION  AND  "PROCEED" 

5.8  IF  THE  DESIRED  ATTRIBUTE  TYPE  IS  DISPLAYED  ON  THE 
RESULTANT  LIST,  SELECT  IT  AND  "PROCEED",  AND  SKIP  THE 
NEXT  STEP. 

5.9  IF  THE  DESIRED  ATTRIBUTE  TYPE  WAS  NOT  FOUND,  ENTER  THE 
NAME  OF  THE  ATTRIBUTE  AND  SELECT  THE  "CREATE"  FUNCTION 

5.10  PERFORM  THESE  STEPS  UNTIL  ALL  THE  ATTRIBUTES  FOR 
THE  GIVEN  ENTITY  OBJECT  HAVE  BEEN  DEFINED 

6  CLOSE  THE  ENTITY  TYPE  DESCRIPTION  WINDOW  CLOSE  THE  SUBJECT 
AREA  ENTITY  VIEW  DIAGRAM,  DESELECT  THE  CURRENT  SUBJECT 
AREA,  SELECT  THE  NEXT  SUBJECT  AREA  AND  CONTINUE  AS 
DESCRIBED  UNTIL  ALL  ENTITY  OBJECTS  HAVE  BEEN  ATTRIBUTED  VIA 
THEIR  RESPECTIVE  SUBJECT  AREA'S  ENTITY  VIEWS 

EVALUATE  ATTRIBUTE  ASSIGNMENTS  TO  ENTITIES 

1  PERFORM  STEPS  OUTLINED  IN  2.1.4.16  AS  NECESSARY 

2  TO  DELETE  AN  ATTRIBUTE: 

2.1  AS  OUTLINED  IN  2.1.4.16,  BRING  UP  THE  ENTITY  TYPE 
DESCRIPTION  THAT  CONTAINS  THE  GIVEN  ATTRIBUTE,  THROUGH 
THE  SUBJECT  AREA  ENTITY  VIEW 

2.2  SELECT  THE  ATTRIBUTE  TO  BE  DELETED 

2.3  PULL  DOWN  THE  "EDIT"  MENU 

2.4  SELECT  THE  "DELETE"  FUNCTION  AND  "PROCEED" 

2.5  "PROCEED" 
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2.1  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 

2.1  DEVELOP  AND  ATTRIBUTE  THE  ENTITY  RELATIONSHIP  MODEL 

Reference  Appendix  D,  DETAILED  PC  DICTIONARY  PROCEDURES,  for  more 
details  on  how  to  ADD,  EDIT,  DELETE,  COPY,  RENAME,  REPORT,  or  QUERY 
dictionary  members. 

2.1.1  PURPOSE 

The  purpose  in  these  PC  DICTIONARY  detailed  procedures  is  to  explain 
how  to  capture  and  report  the  information  that  is  gathered  while 
developing  and  attributing  the  entity  relationship  model. 

2.1.2  COMPONENTS/TERMS 

2. 1.2.1  ONE-ASSOCIATION  TO 

A  One-Association  holds  from  a  source  entity  (the  entity  being  defined) 
to  a  target  entity  such  that  an  instance  of  the  source  entity 
determines  a  single  instance  of  the  target  entity.  This  implies  that 
the  identifier  of  the  target  entity  has  a  functional  dependency  on  the 
identifier  of  the  source  entity.  Example:  Member  being 
defined _ EMPLOYEE 

Sub  Member  Name. .. .MANAGER  (An  employee  has  at  least  one  and  at  most 
one  manager;  1,1) 

Sub  Member  Name. .. .FULL-TIME-EMPLOYEE  (An  employee  can  be  at  least  zero 
full-time  employees  and  at  most  one  full-time  employee;  0,1) 

2. 1.2. 2  ONE-ATTRIBUTES  ARE 

A  One-Attribute  is  an  attribute  whose  value  is  uniquely  determined  by 
each  instance  of  the  source  entity  (the  entity  being  defined).  Each 
instance  of  the  source  entity  (and  thus  each  value  of  the  identifier) 
determines  exactly  one  value  of  the  attribute. 

Example:  Member  being  defined _ EMPLOYEE 

Sub  Member  Name - EMPLOYEE-SEX-CODE  (An  employee  has  at  least  one  and 

at  most  one  sex  code;  1,1) 

Sub  Member  Name. .. .EMPLOYEE-HOME-TELEPHONE-NUMBER  (An  employee  has  at 
least  zero  and  at  most  one  home  telephone  number;  for  our  example,  we 
don't  care  if  they  have  more  than  one  home  telephone  number;  we  will 
only  capture  one;  0,1) 

2. 1.2. 3  MULTI-ASSOCIATION  TO 

A  Multi-Association  holds  from  a  source  entity  (the  entity  being 
defined)  to  a  target  entity  such  that  an  instance  of  the  source  entity 
determines  a  variable  number  of  instances  (perhaps  none)  of  the  target 
entity.  This  implies  that  the  identifier  of  the  target  entity  has  a 
multi-valued  dependency  on  the  identifier  of  the  source  entity. 


162 


Example  1:  Member  being  defined - CONTRACTOR 

Sub  Member  Name _ CONTRACTOR-HISTORY  (A  contractor  has  at  least  zero 

history  information  and  at  most  many  history  information;  0,M) 

Example  2:  Member  being  defined - TEACHER 

Sub  Member  Name. .. .COURSE  (A  teacher  must  teach  at  least  one  course  and 
at  most  many  courses;  1,M) 

2. 1.2. 4  MULTI-ATTRIBUTES  ARE 

A  Multi-Attribute  is  an  attribute  whose  value  is  multiply  determined  by 
each  instance  of  the  source  entity  (the  entity  being  defined).  Each 
instance  of  the  source  entity  (and  thus  each  value  of  the  identifier) 
determines  zero,  one,  or  many  values  of  the  attribute. 

Example:  Member  being  def ined. .. .EMPLOYEE 

Sub  Member  Name. .. .DEPENDENT-NAME  (An  employee  has  at  least  zero 
dependents  and  at  most  many  dependents;  0 , M) 

Sub  Member  Name. .. .LANGUAGE-SPOKEN  (An  employee  has  at  least  one  spoken 
language  and  at  most  many  languages;  1,M) 

2.1.3  INPUT  PRODUCTS 

2. 1.3.1  Conceptual  Entities 
(Get  list  of  Conceptual  Entities) 

2. 1.3. 1.1  Select  CATALOGUE  from  QUERY  MENU. 

2. 1.3. 1.2  Select  query  logic,  EQUAL. 

2. 1.3. 1.3  Enter  catalogue  name,  CONCEPTUAL,  or  select  from  look  up 
list  [F2] . 

2. 1.3. 1.4  Check  report  destination  [ALT-F10]. 

2. 1.3. 1.5  Start  query  [F10] . 

(Get  report  of  Entities  using  the  previous  list) 

2. 1.3. 1.6  Select  MEMBER  DEFINITION  from  REPORT  MENU. 

2. 1.3. 1.7  Select  member(s)  that  were  on  catalogue  query  report  [SPACE 
BAR]. 

2. 1.3. 1.8  Check  report  destination  [ALT-F10]. 

2. 1.3. 1.9  Print  report  [F10-G0]. 

2.1.4  GENERAL  PROCEDURES 

2. 1.4. 5  Briefly  Define  Each  Substantive  Entity  Type  and  Sub-Type 
(Adding  new  Substantive  Entities) 

2. 1.4. 5.1  Add  each  new  Substantive  Entity  Type/Sub-Type. 

2. 1.4. 5. 2  Edit  the  DEFINITION  attribute. 

2. 1.4. 5. 3  Write  one  to  three  sentences  of  definition. 

2. 1.4. 5. 4  Save  the  DEFINITION. 

2. 1.4. 5. 5  Edit  the  CATALOG  attribute. 

2. 1.4. 5. 6  Add  the  CATALOG  'ENTITY'. 
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2. 1.4. 5. 7  Add  another  CATALOG  'SUBSTANTIVE'. 

2. 1.4. 5. 8  Add  another  CATALOG  'SUB  ENTITY',  if  necessary. 

2. 1.4. 5. 9  Save  CATALOGS. 

2.1.4.5.10  Edit  any  other  attributes,  as  needed. 

2.1.4.5.11  Save  new  Entity. 

(Relating  Substantive  Entity  Types  and  Sub-Types) 

2.1.4.5.12  Edit  the  Substantive  Entity  Type. 

2.1.4.5.13  Edit  the  SUB-ENTITIES  ARE  relationship. 

2.1.4.5.14  Add  the  name  of  the  Substantive  Entity  Sub-Type,  or  use  F2 
lookup  to  select  the  name  from  the  list. 

2.1.4.5.15  Save  SUB-ENTITIES. 

2.1.4.5.16  Save  Substantive  Entity  Type. 

2. 1.4. 9  Define  Substantive  Relationships 
(Adding  Substantive  Relationships) 

2. 1.4. 9.1  Add  each  Substantive  Relationship. 

2. 1.4. 9. 2  Edit  the  DEFINITION  attribute. 

2. 1.4. 9. 3  In  one  to  three  sentences,  describe  what  the  relationship 
(verb  phrase)  means  in  relation  to  the  Entity  Types  it  serves  to 
relate. 

2. 1.4. 9. 4  Save  the  DEFINITION. 

2. 1.4. 9. 5  Edit  the  CATALOG  attribute. 

2. 1.4. 9. 6  Add  the  CATALOG  'RELATIONSHIP'. 

2. 1.4. 9. 7  Add  another  CATALOG  'SUBSTANTIVE'. 

2. 1.4. 9. 8  Save  CATALOGS. 

2. 1.4. 9. 9  Edit  any  other  attributes,  as  needed. 

2.1.4.9.10  Save  Substantive  Relationship. 

2.1.4.10  Determine  Cardinalities  in  Substantive  ERD 
(Adding  Cardinalities  to  Relationships) 

2.1.4.10.1  Edit  each  Relationship. 

2.1.4.10.2  Edit  the  8USINESS-RULE  attribute. 

2.1.4.10.3  Describe  the  rules  that  make  this  relationship  necessary. 

2.1.4.10.4  Save  the  BUSINESS-RULE. 

2.1.4.10.5  Save  the  Relationship. 

(Relate  Substantive  Entity  Types) 

2.1.4.10.6  Edit  Substantive  Entity  Type. 

2.1.4.10.7  Edit  ONE-ASSOCIATION/MULTI-ASSOCIATION  relationship. 

2.1.4.10.8  Add  name(s)  of  Substantive  Entity  Type,  or  select  from  F2 
lookup  list. 

2.1.4.10.9  Save  ONE-ASSOCIATION/MULTI-ASSOCIATIONs. 

2.1.4.10.10  Save  Substantive  Entity  Type. 

2.1.4.13  Define  Each  Classifying  Entity  Type  and  Sub-Type 
(Adding  new  Classifying  Entities) 


2.1.4.13.1  Add  each  new  Classifying  Entity  Type/Sub-Type. 

2.1.4.13.2  Edit  the  DESCRIPTION  attribute. 

2.1.4.13.3  Write  one  to  three  sentences  of  description,  embellishing 
the  name  sufficiently  to  understand  what  the  classification  really 
means. 


2.1.4.13.4  Save  the  DESCRIPTION. 

2.1.4.13.5  Edit  the  CATALOG  attribute. 
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2.1.4.13.6  Add  the  CATALOG  'ENTITY'. 

2.1.4.13.7  Add  another  CATALOG  'CLASSIFYING'. 

2.1.4.13.8  Add  another  CATALOG  'SUB  ENTITY',  if  necessary. 

2.1.4.13.9  Save  CATALOGS. 

2.1.4.13.9  Edit  any  other  attributes,  as  needed. 

2.1.4.13.10  Save  new  Entity. 

(Relate  Entity  Types  and  Entity  Sub-Types) 

2.1.4.13. 11  Edit  the  Entity  Type. 

2.1.4.13.12  Edit  the  SUB-ENTITIES  ARE  relationship. 

2.1.4.13.13  Add  the  name  of  the  Entity  Sub-Type,  or  use  F2  lookup  to 
select  the  name  from  the  list. 

2.1.4.13.14  Save  SUB-ENTITIES. 

(Relate  Substantive  Entity  Types  and  Classifying  Entity  Types) 

2.1.4.13.15  Edit  ONE-ASSOCIATION/MULTI-ASSOCIATION  relationship. 

2.1.4.13.16  Add  name(s)  of  Substantive  Entity  Type,  or  select  from  F2 
lookup  list. 

2.1.4.13.17  Save  ONE-ASSOC I AT I ON/MULTI -ASSOC I ATIONs . 

2.1.4.13.18  Save  Entity  Type. 

2.1.4.13.19  Repeat  for  related  Entity  Type. 

2.1.4.13.15  Save  Entity  Type. 

2.1.4.15  Review  and  Revise  Classifying  Entity  Type  and  Sub-Type 
Definitions 

(Editing  Classifying  Entities) 

2.1.4.15.1  Edit  each  Classifying  Entity  Type/Sub-Type. 

2.1.4.15.2  Edit  the  DESCRIPTION  attribute. 

2.1.4.15.3  Make  changes  as  needed. 

2.1.4.15.4  Save  the  DESCRIPTION. 

2.1.4.15.5  Edit  any  other  attributes,  as  needed. 

2.1.4.15.6  Save  Entity. 

2.1.4.16  Identify  Attributes  for  each  Entity  Type  and  Associative 
Entity  Type(i.e.  Substantive  Relationships) 

(Adding  new  Associative  Entities) 


2.1.4.16.1  Add  each  new  Associative  Entity  Type. 

2.1.4.16.2  Edit  the  DESCRIPTION  attribute. 

2.1.4.16.3  Write  one  to  three  sentences  of  description,  explaining  the 
Relationship  that  was  transformed  into  an  Entity. 

2.1.4.16.4  Save  the  DESCRIPTION. 

2.1.4.16.5  Edit  the  CATALOG  attribute. 

2.1.4.16.6  Add  the  CATALOG  'ENTITY'. 

2.1.4.16.7  Add  another  CATALOG  'ASSOCIATIVE'. 

2.1.4.16.8  Save  CATALOGS. 

2.1.4.16.9  Edit  any  other  attributes,  as  needed. 

2.1.4.16.10  Save  new  Associative  Entity  Type. 

(Adding  Context  Attributes) 

2.1.4.16.11  Add  Context  Attribute. 


2.1.4.16.12 

2.1.4.16.13 

2.1.4.16.14 

2.1.4.16.15 

2.1.4.16.16 


Edit  the  DEFINITION. 

Write  a  one  sentence  definition. 

Save  DEFINITION. 

Edit  CATALOG  attribute. 

Add  the  CATALOG  'CONTEXT  ATTRIBUTE'. 
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2.1.4.16.17  Save  CATALOG. 

2.1.4.16.18  Edit  any  other  attributes,  as  needed. 

2.1.4.16.19  Save  Context  Attribute. 

2.1.4.17  Evaluate  Attribute  Assignments  to  Entities 
(Adding  new  Attributes,  name  only,  to  Entities) 

2.1.4.17.1  Edit  each  Entity  Type. 

2.1.4.17.2  Edit  the  ONE-ATTRIBUTE/MULTI-ATTRIBUTE  relationship. 

2.1.4.17.3  Add  the  names  of  the  Attributes,  following  the  naming 
conventions.  This  will  create  a  NULL  Attribute. 

2.1.4.17.4  Save  the  ONE-ATTRIBUTE/MULTI-ATTRIBUTE. 

2.1.4.17.5  Edit  the  IDENTIFIER  relationship. 

2.1.4.17.6  Add  the  name  of  the  Attribute  that  uniquely  identifies  the 
Entity  Type  being  defined,  following  the  naming  conventions.  This  will 
create  a  NULL  Attribute. 

2.1.4.17.7  Save  Entity  Type. 

2.1.5  OUTPUT  PRODUCTS 

2. 1.5. 3  Entity  Type  Definition  Report 

(Get  list  of  Entity  types  that  are  used  in  the  project.) 

2. 1.5. 3.1  Select  CATALOGUE  from  QUERY  MENU. 

2. 1.5. 3. 2  Select  query  logic,  EQUAL. 

2. 1.5. 3. 3  Enter  catalogue  name,  CONTRACTOR  PROFILE,  or  select  from 
look  up  list  [F2] . 

2. 1.5. 3. 4  Select  query  logic,  AND. 

2. 1.5. 3. 5  Select  query  logic,  EQUAL. 

2. 1.5. 3. 6  Enter  catalogue  name,  ENTITY,  or  select  from  look  up  list 
[F2] . 

2. 1.5. 3. 7  Check  report  destination  [ALT-F10]. 

2. 1.5. 3. 8  Start  query  [F10]. 

(Get  report  of  Entities  using  previous  list) 

2. 1.5. 3. 9  Select  MEMBER  DEFINITION  from  REPORT  MENU. 

2.1.5.3.10  Select  one  entity  type  that  was  on  catalogue  query  report 
[SPACE  BAR]. 

2.1.5.3.11  Check  report  destination  [ALT -F 10] . 

2.1.5.3.12  Print  report  [F10-G0]. 

2.1.5.3.13  Repeat  for  each  entity  type. 

2. 1.5. 4  Relationship  Type  Definition  Report 

(Get  list  of  Substantive  and  Classifying  Relationships) 

2. 1.5. 4.1  Select  CATALOGUE  from  QUERY  MENU. 

2. 1.5. 4. 2  Select  query  logic,  EQUAL. 

2. 1.5. 4. 3  Enter  catalogue  name,  SUBSTANTIVE,  or  select  from  look  up 
list  [F2]. 

2. 1.5. 4. 4  Select  query  logic,  AND. 

2. 1.5. 4. 5  Select  query  logic,  EQUAL. 

2. 1.5. 4. 6  Enter  catalogue  name,  CLASSIFYING,  or  select  from  look  up 
list  [F2] . 

2.1.5.4.7  Select  query  logic,  AND. 

2. 1.5. 4. 8  Select  query  logic,  EQUAL. 

2. 1.5. 4. 9  Enter  catalogue  name,  RELATIONSHIP,  or  select  from  look  up 
list  [F2]. 
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2.1.5.4.10  Check  report  destination  [ALT-F10]. 

2.1.5.4.11  Start  query  [F10]. 

(Get  report  of  Relationships  using  previous  list) 

2.1.5.4.12  Select  MEMBER  DEFINITION  from  REPORT  MENU. 

2.1.5.4.13  Select  member(s)  that  were  on  catalogue  query  report 
[SPACEBAR]. 

2.1.5.4.14  Check  report  destination  [ ALT-F10] . 

2.1.5.4.15  Print  report  [F10-GQ]. 

2. 1.5. 5  Attributed  Entities  Report 

Report  in  2. 1.5. 3. 9  gives  the  attributes  for  each  Entity. 

2. 1.5. 6  Attribute  Definition  Report 

(Get  report  of  Context  Attributes  using  Entity  type  report  from 
2. 1.5. 3) 

2. 1.5. 6.1  Select  MEMBER  DEFINITION  from  REPORT  MENU. 

2. 1.5. 6. 2  Select  member(s)  that  are  listed  in  the  ONE/MULTI-ATTRIBUTES 
clause  of  the  entity.  [SPACEBAR]. 

2. 1.5. 6. 3  Check  report  destination  [ALT-F10]. 

2. 1.5. 6. 4  Print  report  [F10-G0]. 

2. 1.5. 6. 5  Repeat  for  each  entity  type. 

Recommend  placing  the  subject  area  ERDS,  entity  type,  and  attribute 
reports  in  a  notebook  with  tabs  separating  each  entity  type.  Each 
section  could  be  ordered  with  an  ERD  first,  the  entity  type  definition 
report,  followed  by  the  attribute  definition  report  for  that  entity 
type. 
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2.2  DECOMPOSE  PROCESSES 


Figure  2.2-1  Step  Overview 
Figure  2.2-2  Step  Products 
Figure  2.2-3  Step  Components 

2.2.1  PURPOSE 

2.2.2  COMPONENTS/TERMS 

2.2.2. 1  Processes 

2. 2. 2. 2  Levels  of  the  Logical  Functional  Architecture 

2. 2. 2. 3  Sequential  Processes 

2. 2. 2. 4  Process  Dependencies 

2.2.3  INPUT  PRODUCTS 

2.2. 3.1  LIA  CRUD  Association  Matrix 

2. 2. 3. 2  Function  and  Process  Reports 

2.2. 3. 3  Entity  Type  Reports 

2.2.4  GENERAL  PROCEDURES 

2.2.4. 1  Review  LIA  CRUD  Association  Matrix 

2. 2. 4. 2  Review  Function,  Process,  and  Entity  Reports 

2. 2. 4. 3  Select  and  Decompose  Processes 

2. 2. 4. 4  Develop  Process  Dependency  Diagrams  (DEP-Ds) 

2. 2.4. 5  Develop  Process  Decomposition  Diagrams 

2. 2. 4. 6  Define  characteristics  of  in-scope  processes 

2.2.5  OUTPUT  PRODUCTS 

2. 2. 5.1  Process  Dependency  Diagrams 

2. 2. 5. 2  Process  Decomposition  Diagrams 

2. 2. 5. 3  Process  Reports 

2.2.6  RULES 

2.2.6. 1  Adherence  to  scoping  criteria 

2. 2. 6. 2  Mutual  exclusivity 

2. 2. 6. 3  Exhaustiveness 

2. 2. 6. 4  Naming  conventions  and  definitions 

2. 2. 6. 4.1  Process  Naming  Conventions 

2. 2. 6. 4. 2  External  Agent  Naming  Conventions 

2. 2. 6. 4. 3  Data  Flow  Naming  Conventions 

2. 2. 6. 4. 4  Process  Dependency  Naming  Conventions 

2. 2. 6. 5  Life  Cycle  Rules 

2.2.7  EXAMPLES 

Figure  2.2. 7-1  IEW  LIA  CRUD  Association  Matrix  (Level  0 
Only) 

Figure  2. 2. 7-2  IEW  Function  Report  (For  Function  AA) 
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Figure  2.2. 7-3  IEW  LIA  Entity  Report  (For  Legal  Entity) 
Figure  2. 2. 7-4  IEW  Leve;  0  DEP-D  (For  Function  AA) 
Figure  2.2. 7-5  IEW  Process  Decomp  Diagram  (Level  0  Thru 
1) 

Figure  2. 2. 7-6  IEW  Level  1  DEP-D  (For  Process  AAA) 
Figure  2. 2. 7-7  IEW  Process  Decomp  Diagram  (Level  0  Thru 
2) 

Figure  2.2. 7-8  IEW  Process  Report  (Process  AAAB) 


2.2  Appendix  A  -  Detailed  IEW  Procedures 

2.2  Appendix  B  -  Detailed  PC  Dictionary  Procedures 
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2.2  DECOMPOSE  PROCESSES 


This  module  addresses  the  functional  architecture  and  results  in  the 
establishment  of  the  relationships  between  functions  and  processes. 

2.2.1  PURPOSE 

Process  Dependency  Diagrams  (DEP-Ds)  and  Process  Decomposition 
Diagrams  (DEC-Ds)  are  developed  in  this  step  to  present  the 
processing  structure  of  selected  functions.  Each  high-level  process 
can  also  have  a  structure  of  subprocesses  within  it.  The  "breadth", 
or  horizontal  structure  of  a  function  or  process  shows  the  life-cycle 
of  the  processes,  and  the  "depth"  shows  the  hierarchical  work 
breakdown  structure. 

When  the  diagrams  are  complete  they  can  be  used  by  the  members  of  the 
team  to  find  anomalies  and  conflicts  in  the  workbreakdown  structure 
of  the  function  or  process.  The  diagrams  are  used  to  resolve 
inter-function  and  inter-process  discrepancies  in  an  iterative, 
increasingly  detailed,  top-down  fashion.  The  objective  of  this  step 
is  to  decompose  the  processes  into  the  lowest  level  of  process.  The 
lowest  level  processes  will  then  be  further  decomposed  into  "Actions" 
which  create,  retrieve,  update,  and  delete  data. 
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2.2.2  COMPONENTS/TERMS 

2.2.2. 1  Processes 

A  process  is  a  low  level  action  or  group  of  actions  that  starts  or 
stops  and  is  repeatedly  executed  in  a  defined  sequence .  It  has 
identifiable  inputs  and  outputs  expressed  as  information  views  of  the 
data  architecture.  Each  execution  of  a  process  produces  a 
specification  kind  of  effect  on  entities  and  their  attributes.  A 
process  describes  what  a  business  does,  not  where,  or  when  it  does 
things.  Processes  may  be  performed  by  more  than  one  organizational 
unit  in  a  physical  system.  Processes  are  identified  and  described  at 
the  logical  level  of  modeling.  Processes  may  in  turn  be  decomposed 
into  lower  level  process  (subprocesses)  and  actions. 

2. 2. 2. 2  Levels  of  the  Logical  Functional  Architecture 

The  Logical  Functional  Architecture  is  the  detailed  structuring  of 
one  area  of  the  of  the  Conceptual  Functional  Architecture.  It  is  a 
view  of  that  architecture  based  on  one  or  more  methods  of  defining  an 
area  for  logical  analysis.  The  functional  architecture  is  decomposed 
in  levels  as  follows:  Functions,  Processes,  Sequential  Processes, 
Actions.  All  functions  which  were  selected  in  the  Scoping  Phase  are 
considered  to  be  level  0  of  the  Logical  Functional  Architecture.  The 
first  level  of  processes  within  all  decomposed  functions  is  level  1 
of  the  Logical  Functional  Architecture.  Processes  are  decomposed 
hierarchically  until  the  level  where  actions  on  entities  are  reached 
(i.e.,  where  Creation,  Retrieve,  Update,  and  Deletion  of  data  starts 
occurring).  The  level  just  above  the  actions  is  the  "leaf"  process, 
also  called  a  "sequential"  process.  There  can  be  multiple  levels  of 
processes,  one  level  of  function,  one  level  of  sequential  process, 
and  multiple  levels  of  actions.  Diagrams  are  created  for  level  0 
functions,  processes  and  actions  at  each  level  as  follows: 


DIAGRAM: 

LEVEL 

IN-SCOPE? 

DEP-D 

DEC-D 

ACTION 

DIAG 

FUNCTION  A 

0 

YES 

NO 

YES 

NO 

FUNCTION  AA 

1 

YES 

YES 

YES 

NO 

PROCESS  AAA 

2 

NO 

YES 

YES 

NO 

PROCESS  AAB 

2 

YES 

YES 

YES 

NO 

SEQUENTIAL  PROCESS  AABA 

3 

NO 

NO 

NO 

NO 

SEQUENTIAL  PROCESS  AABB 

3 

YES 

NO 

NO 

YES 

ACTION  AABBA 

4 

YES 

NO 

NO 

YES 

ACTION  AABBAA 

5 

YES 

NO 

NO 

NO 

ACTION  AABBAB 

5 

YES 

NO 

NO 

NO 

ACTION  AABBB 

4 

YES 

NO 

NO 

NO 

FUNCTION  AB 

1 

NO 

NO 

NO 

NO 

PROCESS  ABA 

2 

NO 

NO 

NO 

NO 

PROCESS  ABB 

2 

NO 

NO 

NO 

NO 

Each  function  and  process  is  decomposed  by  defining  all  of  the 
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processes  within  it.  Only  those  processes  which  in  some  way  use  the 
entities  which  are  within  the  scope  of  the  Subject  Area  are  further 
decomposed. 

2. 2. 2. 3  Sequential  Processes 

Sequential  processes  are  the  lowest  levels  of  the  decomposed  process 
hierarchy.  Sequential  processes  are  composed  of  "actions"  (i.e., 
Create,  Retrieve,  Update,  or  Delete).  Each  sequential  process  within 
the  scope  of  the  functional  architecture  will  be  decomposed  into 
action  diagrams  in  the  unit  analysis  phase  of  the  Logical  Information 
Architecture  development. 

2. 2. 2. 4  Process  Dependencies 

Process  dependency  exists  when  one  process  depends  on  other  processes 
to  complete  a  task.  The  dependency  can  occur  because  processes 
require  information  from  other  processes.  Dependencies  indicate  the 
sequence  in  which  executions  of  processes  must  occur,  whether  they 
may  be  carried  out  in  parallel  with  other  processes,  and  whether  they 
are  mutually  exclusive  of  each  other.  Processing  sequence  will  also 
change  when  the  processes  are  viewed  from  the  differing  life  cycle 
perspectives  of  different  entities.  Dependencies  serve  as  basis  for 
procedure  design  during  physical  modeling. 

The  type  of  dependency  between  processes  which  is  shown  in  Process 
Dependency  Diagrams  (DEP-Ds)  is  the  general  life  cycle  sequence  of 
the  primary  entities  of  the  enterprise.  The  primary  entity  of  DLA  is 
ITEM.  The  sequence  of  processes  at  each  level  in  the  process 
hierarchy  should  therefore  be  arranged  according  to  the  sequence  for 
processing  items. 
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2.2.3  INPUT  PRODUCTS 

2.2. 3.1  LIA  CRUD  Association  Matrix  (Figure  2. 2. 7-1) 

See  previous  definitions. 

2. 2. 3. 2  Function  and  Process  Reports  (Figure  2. 2. 7-2,  2. 2. 7-8) 
See  previous  definitions. 

2. 2. 3. 3  Entity  Type  Reports  (Figure  2. 2. 7-3) 

See  previous  definitions. 
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2.2.4  GENERAL  PROCEDURES 

2.2.4. 1  Review  LIA  CRUD  Association  Matrix 

Review  the  functions  and  processes  in  the  LIA  CRUD  Association 
Matrix.  During  the  first  iteration  of  this  step,  only  functions  will 
appear  in  the  CRUD  Association  Matrix.  If  no  processes  have  been 
added  to  the  matrix  then  identify  the  "level  0"  functions  which  have 
and  have  not  been  decomposed.  If  processes  have  been  added,  then 
identify  which  functions  or  processes  are  the  parents  and  which  are 
descendents. 

2. 2. 4. 2  Review  Function,  Process,  and  Entity  Reports 

Review  the  definitions  of  each  function  and  process  contained  within 
the  LIA  which  have  been  developed  to  date.  Review  the  entity  reports 
(of  those  entities  which  are  within  scope)  to  determine  which 
processes  use  the  entities  and  should  therefore  be  further 
decomposed. 

2. 2. 4. 3  Select  and  Decompose  Processes 

Select  processes  which  have  been  determined  to  be  within  scope  and 
decompose  them  according  to  the  rules.  The  first  level  to  be 
decomposed  is  for  selected  level  0  functions.  Decompose  all  Level  0 
functions  into  all  of  their  level  1  processes.  Indicate  the  sequence 
of  process  occurrence  of  all  level  1  processes  using  process 
dependency  diagrams  and  the  life  cycle  rules. 

Prior  to  defining  level  2  of  the  functional  information  architecture, 
conduct  the  remaining  steps  within  the  Global  Analysis  Phase.  During 
the  Review  Scope  step,  those  processes  which  are  within  scope  will  be 
identified  so  that  they  can  be  decomposed  in  the  next  iteration  of 
this  step.  Those  processes  which  are  out-of-scope  will  not  be  further 
decomposed. 

2. 2. 4. 4  Develop  Process  Dependency  Diagrams  (DEP-Ds) 

Develop  DEP-Ds  for  all  processes  in  the  functional  architecture  which 
are  within  scope.  The  first  "unit"  to  diagram  will  be  the  first 
level  0  function.  Once  all  of  the  level  0  functions  have  completed 
DEP-Ds  then,  after  the  other  steps  have  been  completed  for  level  0 
and  the  out-of-scope  processes  have  been  identified,  the  DEP-Ds  for 
selected  level  1  processes  can  be  prepared  (Figure  2. 2. 7-4  and 
2. 2. 7-6). 

2.2.4. 5  Develop  Process  Decomposition  Diagrams 

Process  Decomposition  Diagrams  (DEC-Ds)  are  automatically  generated 
by  the  automated  tools.  DEC-Ds  depict  the  hierarchical  structure  of 
the  Logical  Information  Architecture.  The  general  sequence  of  the 
occurrence  of  processes  should  be  from  left  to  right  across  the  page. 
(Figure  2.2. 7-5  and  2. 2. 7-7). 
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2. 2. 4. 6  Define  characteristics  of  in-scope  processes 

Each  process  which  is  added  to  the  logical  functional  architecture 
and  which  is  determined  to  be  within  the  scope  of  the  subject  area 
needs  to  be  described.  Full  descriptions  should  be  entered  as 
required  by  each  automated  tool  (Figure  2. 2. 7-8). 
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2.2.5  OUTPUT  PRODUCTS 

2.2. 5.1  Process  Dependency  Diagrams  (Figure  2. 2. 7-4,  2.2. 7-6) 

Process  Dependency  Diagrams  (DEP-Ds  are  pictorial  representations  of 
the  flow  of  data  through  an  enterprise  or  computerized  system. 

DEP-Ds  declare  the  existence  of  processes  which  transform  data  and 
their  interfaces.  DEP-D's  are  network  presentations  of  a  system, 
whether  automated,  manual,  or  mixed.  They  declare  component  pieces  of 
the  system  and  the  interfaces  among  them. 

2.2. 5.2  Process  Decomposition  Diagrams  (Figure  2.2. 7-5,  2. 2. 7-7) 

2.2. 5. 3  Process  Reports  (Figure  2. 2. 7-8) 
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2.2.6  RULES 


2.2.6. 1  Adherence  to  scoping  criteria 

All  processes  to  be  decomposed  must  support  the  scoping  criteria 
(i.e.,  Objectives  and  Information  Requirements). 

2. 2. 6. 2  Mutual  exclusivity 

All  processes  must  be  mutually  exclusive  at  the  same  level  of  their 
respective  hierarchy. 

2. 2. 6. 3  Exhaustiveness 

All  processes  at  one  level  of  a  hierarchy  must  completely  exhaust  the 
parent  function. 

2. 2. 6. 4  Naming  conventions  and  definitions 
2. 2. 6. 4.1  Process  Naming  Conventions 


Format: 

PROCESS  HIERARCHY/SEQUENCE  NUMBER  +  VERB  WORD  +  NOUN  WORD(S)  ANO 
ADJECTIVES 

PROCESS  HIERARCHY/SEQUENCE  NUMBER  examples: 

AA  -  Function 

AAA  -  Process  within  function  AA 
AAAA  -  Descendent  process  within  AAA 

AAAB  -  Descendent  process  within  AAA  AAB  -  Process  within  function 
AA 

VERB  WORD  examples: 

Assign,  assure,  perform,  resolve,  evaluate,  implement,  receive, 
issue,  monitor,  conduct,  provide,  close,  conduct,  apply,  dispose, 
identify. 

NOUN  WORDS  AND  ADJECTIVES  examples: 

Item,  Legal  Entity,  Offer,  Contract,  contractor,  responsibilities, 
contract  award,  unsuccessful  offerors,  viable  industrial  base, 
purchase  request,  exceptions,  progress  reviews,  payment,  evaluation 
factors,  performance. 

Abbreviate  verb  words  and  noun  words  if  necessary  to  keep  the  entire 
process  name  to  32  characters. 

2. 2. 6. 4. 4  Process  Dependency  Naming  Conventions 

Process  dependencies  are  indicated  on  DEP-Ds  by  the  lines  which 
connect  processes.  The  names  of  the  dependency  lines  indicate  two 
processes  which  are  dependent  upon  each  other. 
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Format: 


PROCESS  HIERARCHY  SEQUENCE  NUMBER  TO  PROCESS  HIERARCHY  SEQUENCE 
NUMBER 

Examples: 

AAB  TO  AAC 
AAC  TO  AAD 

2. 2. 6. 5  Life  Cycle  Rules 

Processes  are  executed  either  serially  or  in  parallel.  Processes 
should  be  depicted  on  DEP-Ds  from  left  to  right  on  the  page;  this 
indicates  that  they  are  executed  in  a  sequence  starting  from  the  left 
and  progressing  leftward  and  downward  across  the  page.  When  two  or 
more  processes  are  executed  in  parallel  then  still  show  them  in  a 
sequence  on  the  DEP-Ds.  The  sequence  that  parallel  processes  are 
shown  in  does  not  matter.  (The  entity  life  cycle  matrices  will  show 
the  proper  sequence  of  execution  of  parallel  processes.) 

The  life  cycle  sequences  of  processes  are  determined  by  when  they  act 
on  entities.  The  actions  which  processes  have  on  entities  are 
Create,  Retrieve,  Update,  and  Delete  (CRUD). 

The  life  cycle  of  the  entity  which  is  of  most  concern  to  the 
enterprise  should  determine  the  sequences  of  processes.  The  primary 
entity  of  the  Defense  Logistics  Agency  (DLA)  is  "item."  Therefore, 
the  life  cycle  of  "items"  should  be  the  first  determinant  of  process 
sequence.  The  secondary  determinants  should  be  the  life  cycles  of 
the  conceptual  entities  which  have  been  selected  as  part  of  the 
scoping  process. 
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2.2.7  EXAMPLES 


Figure  2. 2. 7-1  IEW  LIA  CRUD  Association  Matrix  (Level  0  Only) 
Figure  2. 2. 7-2  IEW  Function  Report  (For  Function  AA) 

Figure  2.2. 7-3  IEW  LIA  Entity  Report  (For  Legal  Entity) 

Figure  2. 2. 7-4  IEW  Leve;  0  DEP-D  (For  Function  AA) 

Figure  2. 2. 7-5  IEW  Process  Decomp  Diagram  (Level  0  Thru  1) 
Figure  2. 2. 7-6  IEW  Level  1  DEP-D  (For  Process  AAA) 

Figure  2. 2. 7-7  IEW  Process  Decomp  Diagram  (Level  0  Thru  2) 
Figure  2. 2. 7-8  IEW  Process  Report  (Process  AAAB) 
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AA  PURCHASE  REO  PROCESSING  (F) 

AS  OFFER  EVALUATION  (F) _ 

AC  CONTRACT  AMARO  (F) _ 

AO  CONTRACT  ADMINISTRATION  (F) 

A£  FORWARD  PRICE  RATE  OEV  (F) 

AF  CONTRACTOR  SYSTEM  REVIEW  (F) 
BA  MOBILIZATION  SED’fOfT  DET  (F) 
BG  IPP  CAM3IDATE  ITEM  KENT  (F) 
BC  PROG  PUWING  SOC  OEV  (F) 

BO  DEVELOP  IPP  PACKAGE  (F) 


R 

R 

CRU 

CRU 

R 

CRU 

R 


R 

RU 

CRU 

CRU 

CRU 

CRU 

RU 

RU 

RU 

R 


Proe«»»  involv»«  Entity  Typ« 


Figure  2. 2. 7-1  IEW  CRUD  Association  Matrix  (Level  0  Only) 


MOW _ 

AL  ENTITY _ 

Purpose _ 

FIKDAACXTAL 

(FWDAfCNTAL,  ASSOCIATIVE,  ATTRIBUTIVE,  OTTER 

Definition _ 

LEGAL  ENTITY  IS  A  PERSON  OR  GROUP  OF  PERSONS ,  A  CORPORATION  OR  OTTER 
EXISTENCE  RECOGNIZED  BY  LAN  AS  HAVING  RIGHTS  AMD  DUTIES.  THIS 
INCLUDES:  A  HANLFACTIRER ,  SLPPLIER,  DEALER,  VEHXR  OR  DISTRIBUTOR. 

Contents _ 

AUDIT  TRAIL:  LEGAL  ENTITY  INCLUDES  SOLRCE,  OFFEROR,  CONTRACTOR, 
SUBCONTRACTOR,  PRE-AWARD  SUWEY,  PRE-AWARD  SIFVEY  REOLEST,  CAPABILITY, 
CONTRACTOR  HISTORY,  CONTRACTOR  SYSTEM,  CONTRACTOR  SYSTEM  REVIEW, 
CONTRACTOR  SYSTEM  CORRECTIVE  ACTION,  CONTRACT  QUALITY  ASSLRANCE, 
FINDING ,  FORWARD  PRICE  RATE,  PROCEDURE  EVALUATION,  P90CHXJE  REVIEW, 
QUALITY  DATA  EVALUATION,  AMD  SURVEILLANCE. _ 

Lost  Update 

706/23  08:43  (©USER 


I 

Figure  2. 2. 7-2  IEW  Function  Report  (For  Function  AA) 
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Norn _ 

V.  ENTITY _ 

Purpose _ 

FUOWgffAL 

(FUNDAfCNTAL,  ASSOCIATIVE,  ATTRIBUTIVE,  OTTER 

Definition _ 

LEGAL  ENTITY  IS  A  PERSON  OR  GROP  OF  PERSONS,  A  CORPORATION  OR  OTHER 
EXISTENCE  RECOGNIZED  BY  LAM  AS  HAVING  RIGHTS  AW  DUTIES.  THIS 
INCLUDES:  A  KAKFACTlfiER,  SUPPLIER,  DEALER,  VEWCR  OR  DISTRIBUTOR. 

Comcnts _ 

AUDIT  TRAIL:  LEGAL  ENTITY  INCLUES  SOURCE,  OFFEROR,  CONTRACTOR, 
SUBCONTRACTOR,  PRE-AWARD  SIFVEY,  PRE-AWARD  SURVEY  REQUEST,  CAPABILITY, 
CONTRACTOR  HISTORY,  CONTRACTOR  SYSTEM,  CONTRACTOR  SYSTEM  REVIEW, 
CONTRACTOR  SYSTEM  CORRECTIVE  ACTION,  CONTRACT  QUALITY  ASSUWNCE, 
'DOING,  FORWARD  PRICE  RATE,  PROCEDURE  EVALUATION,  PROCEDURE  REVIEW, 
QUALITY  DATA  EVALUATION,  AW  SURVEILLANCE. _ 

Lost  Update 

708/23  08:43  WWUSER 


Figure  2. 2. 7-3  IEW  LIA  Entity  Report 
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Figure  2.2.7-A  IFW  Level  O  Dependency  Diagram 
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Figure  2. 2. 7-7  TEW  Process  Decomposition  Diagram  (Level  0  thru  2) 


Page  1 


Information  Engineering  Workbench  Report 

Object  Summary  Report 

July  3,  1990  10:05:07  NEWUSER  V06 

Process  AAAB  VALIDATE  PR  FOR  ADMIN  COMP 

PROPERTIES: 

DEFINITION: 

VALIDATE  PR  FOR  ADMINISTRATIVE  COMPLETENESS 


THIS  PROCESS  REVIEWS  THE  COMPLETE  PR  TO  ENSURE  THAT  ALL  THE  LANGUAG 
CORRECT  AND  COMPLETE,  FOR  EXAMPLE: 


A.  VALIDATE  DESCRIPTIVE  NSN  DATA  ■ 

B.  REVIEW  TECHNICAL  DATA  FILE  (ITEM  DATA)  ■ 

C.  REVIEW  PAST  BUY  HISTORY  (CONTRACTS).  CURRENT  AND  CLOSED  CONTRACTS 

FOR  THE  LAST  FIVE  YEARS  (CONTRACT  HISTORY)  ■ 

D.  REVIEW  CONTRACTING  GUIDANCE  DATA  ■  I 

E.  ENSURE  THAT  COMMITMENT  AUTHORITY  HAS  BEEN  ESTABLISHED 


Figure  2. 2. 7-8  IEW  Process  Report  (Process  AAAB) 


190 


2.2  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 

2.2  DECOMPOSE  PROCESSES 

2.2.1  PURPOSE 

2.2.2  COMPONENTS/TERMS 

2.2.3  INPUT  PRODUCTS 

2.2.4  GENERAL  PROCEDURES 

2.2.4. 1  REVIEW  LIA  CRUD  ASSOCIATION  MATRIX 

2. 2. 4. 1.1  LOGON  TO  PLANNING  WORKBENCH 

2. 2. 4. 1.2  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  'ASSOCIATION 
MATRIX' 

2. 2. 4. 1.3  SELECT  'PROCESS'  IN  THE  TOP  PORTION  OF  THE  DIALOGUE  BOX 

2. 2. 4. 1.4  SELECT  'BY  ENTITY  TYPE'  IN  THE  BOTTOM  PORTION  OF  THE 
DIALOGUE  BOX  AND  CLICK  ON  THE  'PROCEED'  RADIO  BUTTON 

2. 2. 4. 1.5  TO  DISPLAY  A  PARTICULAR  SET  OF  PROPERTIES 

2. 2. 4. 1.5.1  PULL  DOWN  THE  'ASSOCIATION  MATRIX'  MENU  AND  SELECT 
'SHOW  PROPERTIES' 

2. 2. 4. 1.5. 2  SELECT  THE  TYPE  OF  PROPERTIES  YOU  WISH  DISPLAYED 
('ACTION'  FOR  'CRUD'  PROPERTIES  OR  'LIFE  CYCLE  STAGE' 
FOR  LIFE  CYCLE  SEQUENCES) 

2. 2. 4. 1.6  TO  CHANGE  A  PROPERTY  (ADO,  MODIFY,  OR  ERASE) 

2. 2. 4. 1.6.1  CLICK  ON  THE  BOX  AT  THE  JUNCTION  OF  THE  PROCESS  AND 
ENTITY  WHOSE  RELATIONSHIP  ENGENDERS  THE  PROPERTIES  YOU 
WISH  TO  CHANGE 

2. 2. 4. 1.6. 2  TYPE  IN  THE  PROPERTIES  THAT  CORRECTLY  DESCRIBE  THE 
RELATIONSHIP  OF  THE  GIVEN  PROCESS  AND  ENTITY  (ENTER 
BLANKS  TO  WIPE  OUT  AN  EXISTING  PROPERTY) 

2. 2. 4. 2  REVIEW  FUNCTION,  PROCESS,  AND  ENTITY  REPORTS 

2. 2. 4. 2.1  LOGON  TO  PLANNING  WORKBENCH 

2. 2. 4. 2. 2  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  THE  'OBJECT  LIST' 

2. 2. 4. 2. 3  CLICK  ON  THE  RADIO  BOX  NEXT  TO  THE  TYPE  OF  THE  OBJECT 
WHOSE  REPORT  YOU  WISH  TO  REVIEW  ('FUNCTION',  'PROCESS',  OR 
'ENTITY  TYPE'),  AND  CLICK  ON  THE  'PROCEED'  RADIO  BUTTON 

2. 2. 4. 2. 4  SELECT  THE  PARTICULAR  OBJECT  YOU  WANT  (ONLY  ONE  AT  A  TIME) 

2. 2. 4. 2. 5  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  'DETAILS' 

2.2.4. 3  SELECT  AND  DECOMPOSE  PROCESSES 

2. 2. 4. 4  DEVELOP  PROCESS  DEPENDENCY  DIAGRAMS 

2. 2. 4. 4.1  LOGON  TO  ANALYSIS  WORKBENCH 

2. 2. 4. 4. 2  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  'DATA  FLOW 
DIAGRAM' 

2. 2. 4. 4. 3  CLICK  ON  THE  'FIND'  RADIO  BUTTON  IN  THE  DIALOGUE  BOX 
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2. 2. 4. 4. 4  SELECT  THE  PROCESS  WHOSE  SUBPROCESSES  YOU  WISH  TO  ARRANGE 
WITHIN  A  PROCESS  DEPENDENCY  DIAGRAM 

2. 2. 4. 4. 5  REVIEW  THE  IEW  ANALYSIS  WORKBENCH  MANUAL  FOR  DETAILS 
REGARDING  THE  CREATION  OF  DATA  FLOW  DIAGRAMS 

2. 2. 4. 5  DEVELOP  PROCESS  DECOMPOSITION  DIAGRAMS 

2.2.4. 5.1  LOGON  TO  ANALYSIS  WORKBENCH 

2.2.4. 5.2  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  'DECOMPOSITION 
DIAGRAM' 

2. 2. 4. 5. 3  CLICK  ON  THE  RADIO  BUTTON  NEXT  TO  THE  WORD  'PROCESS',  AND 
THEN  CLICK  ON  THE  'FIND'  RADIO  BUTTON 

2. 2. 4. 5. 4  SELECT  THE  PROCESS  WHOSE  DECOMPOSITION  YOU  WISH  TO 
REVIEW/CREATE/MODIFY,  AND  CLICK  ON  THE  'PROCEED'  RADIO 
BUTTON 

2. 2. 4. 5. 5  REVIEW  THE  IEW  ANALYSIS  WORKBENCH  MANUAL  FOR  DETAILS 
REGARDING  THE  USE  OF  THE  DECOMPOSITION  DIAGRAMMER 


192 


2.2  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 

2.2  DECOMPOSE  PROCESSES 

Reference  Appendix  D,  GENERAL  PC  DICTIONARY  PROCEDURES,  for  more 
details  on  how  to  ADD,  EDIT,  DELETE,  COPY,  RENAME,  REPORT,  or  QUERY 
dictionary  members. 

2.2.1  PURPOSE 

The  purpose  of  these  PC  Dictionary  procedures  is  to  explain  how  to 
capture  and  report  the  information  that  is  gathered  while  decomposing 
processes. 

2.2.2  COMPONENTS/TERMS 

2.2.3  INPUT  PRODUCTS 


2.2. 3. 3  Entity  Reports 

Reference  section  1.3  output  products. 

2.2.4  GENERAL  PROCEDURES 


2. 2. 4. 6  Define  characteristics  of  in-scope  processes 
(Add  new  children  Processes) 


2. 2. 4. 6.1 

2. 2. 4. 6. 2 

2. 2. 4. 6. 3 

2. 2. 4. 6. 4 

2. 2. 4. 6. 5 

2. 2. 4. 6. 6 

2. 2. 4. 6. 7 

2. 2. 4. 6. 8 

2. 2. 4. 6. 9 

2.2.4.6.10 

2.2.4.6.11 

2.2.4.6.12 

2.2.4.6.13 

2.2.4.6.14 

2.2.4.6.15 

2.2.4.6.16 

2.2.4.6.17 

2.2.4.6.18 

2.2.4.6.19 


Add  each  new  Process,  following  Naming  Conventions. 

Edit  Catalog. 

Add  Catalog  of  PROCESS. 

Add  another  Catalog  of  CONTRACTOR  PROFILE. 

Save  Catalogs. 

Edit  Decomposition-Text. 

Enter  any  textual  information  that  will  help  in  later 
decomposition  of  the  process  being  defined. 

Save  Decomposition-Text. 

Edit  Description. 

Enter  text  describing  the  process. 

Save  Description. 

Edit  any  other  attributes  as  needed. 

Save  new  Process. 

(Update  previous  level  parent  Processes/Functions) 

Edit  previous  level  Process/Function. 

Edit  Contains. 

Enter  name(s)  of  children  Processes,  or  select  from  F2 
lookup  list. 

Save  Contains. 

Edit  any  other  attributes  as  needed. 

Save  Process/Function. 


2.2.5  OUTPUT  PRODUCTS 


2.2. 5.3  Process  Reports 

(Refer  to  decomposition  diagram) 

2. 2. 5. 3.1  Refer  to  Member  Definition  report  procedures  in  Appendix  D, 
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2.2. 5. 3.2 

2. 2. 5. 3. 3 

2. 2. 5. 3. 4 


2. 2. 5. 3. 5 


GENERAL  PC  DICTIONARY  PROCEDURES. 

Select  one  process  from  decomposition  diagram. 

Run  report. 

Repeat  for  each  process  on  the  diagram.  (This  method  allows 
easy  updating  to  the  hardcopy  products  by  providing  the 
ability  to  edit  each  process  and  reprint  it  without  having 
to  print  the  whole  list  again.) 

Place  hardcopy  report  in  notebook. 


2.2. 5.4  Process  Decomposition  Report 


2.2. 5.4.1 

2. 2. 5. 4. 2 

2. 2. 5. 4. 3 

2. 2. 5. 4. 4 

2. 2. 5. 4. 5 


Select  QUERY  from  MAIN  MENU. 

Select  WHAT  CONSTITUTES  from  QUERY  menu. 

Select  INDIRECTLY. 

Select  Function  or  Process  that  is  at  the  top  of  the 
hierarchy. 

Run  Report. 
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2.3  ASSOCIATE  PROCESSES  AND  ENTITIES 


In  this  step  the  Functional  and  Data  Architecture  are  related  together 
via  association  matrices.  First,  the  "CRUD"  actions  which  are 
performed  by  each  process  on  the  entities  are  identified.  Next, 
wherever  processes  perform  CRUD  actions  on  an  entity,  the  sequence  of 
the  performance  of  the  processes  is  identified. 
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2.3.1  DEVELOP  CRUD  MATRIX 


Figure  2. 3. 1-1  Step  Overview 
Figure  2.3. 1-2  Step  Products 
Figure  2. 3. 1-3  Step  Components 

2. 3. 1.1  Purpose 

2. 3. 1.2  Components 

2. 3. 1.2.1  Entities 

2. 3. 1.2. 2  Processes 

2. 3. 1.2. 3  Action 

2. 3. 1.3  Input  Products 

2. 3. 1.3.1  CRUD  Matrix  (empty) 

2. 3. 1.4  General  Procedures 

2. 3. 1.4.1  Display  empty  CRUD 

2. 3. 1.4. 2  Identify  Actions 

2. 3. 1.5  Outputs 

2. 3. 1.5.1  CRUD  Matrix  (completed) 

2. 3. 1.6  Rules 

2. 3. 1.6.1  Inheritance 

2. 3. 1.6. 2  Restrictions  on  Children 

2. 3. 1.6. 3  Data  Control 

2. 3. 1.7  Examples 

Figure  2. 3. 1.7-1  Sample  CRUD  (empty  cells  for  current 
decomposition  level 

Figure  2. 3. 1.7-2  Sample  CRUD  (completed  cells  for 

current  decomposition  level) 

2.3.1  Appendix  A  -  Detailed  IEW  Procedures 

2.3.1  Appendix  B  -  Detailed  PC  Dictionary  Procedures 
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PROCESS 

DEPENDENCIES 
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STEP  OVERVIEW 


MAPS 


MAPS 


CRUD  ACTIONS 


PROCESS 

SEQUENCE 

NUMBERS 

SCREEN  LASELS 


USER  VIEW/ 
CREW  LAYOUT 
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SCREW 

STANDARD 

SCREW 

CONTEXTUAL 
OUTPUT  DATA 


DATA 

ARCHITECTURE 
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DEPUSDON 
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DC  NOTION 
REPORT 


FUNCTIONS/ 
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ARCHITECTURE 
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2.3.1  DEVELOP  CRUD  MATRIX 

2. 3. 1.1  Purpose 

The  purpose  of  this  step  is  to  map  the  Logical  Functional  Architecture 
(Processes)  to  the  Logical  Data  Architecture  (Entities)  at  each  level 
of  Global  Analysis.  The  mapping  is  accomplished  by  identifying  the 
Actions  of  processes  on  entities. 
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2. 3. 1.2  Components 

2. 3. 1.2.1  Entities 

2. 3. 1.2. 2  Processes 

2. 3. 1.2. 3  Action 

An  action  is  the  component  that  maps  the  Functional  Architecture  to 
the  Data  Architecture  at  both  the  Conceptual  and  Logical  levels  of  the 
Information  Architecture.  At  the  Conceptual  level,  Functions  are 
mapped  to  Entities.  At  the  Logical  level,  Processes  are  mapped  to 
Entities.  The  action  identifies  how  functions  or  processes  use  Entity 
data.  There  are  four  types  of  use  (Actions)  CREATE  an  Entity 
occurence,  RETRIEVE  an  Entity  occurence,  UPDATE  data  within  an  Entity 
occurence,  and  ARCHIVE  an  Entity  occurence.  A  blank  cell  implies  no 
action.  UPDATE  is  used  when  adding  or  changing  data  within  an  Entity 
occurrence. 


201 


2. 3. 1.3  Input  Products 

2. 3. 1.3.1  CRUD  Matrix  (empty)  (Figure  2. 3. 1.7-1) 
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2. 3. 1.4  General  Procedures 

2. 3. 1.4.1  Display  empty  CRUD 

Construct  a  Matrix  Diagram  with  Processes  for  the  rows  and  Entities 
for  the  columns.  The  cells  for  the  current  level  of  Global  Analyis 
will  be  left  blank.  Fill  in  the  higher  levels  (parents,  grandparents, 
etc.)  based  on  previous  CRUD  analyses. 

2. 3. 1.4. 2  Identify  Actions 

For  each  cell  of  the  current  level  of  Global  Analysis,  indicate  the 
action  of  the  Process  on  the  Entity.  Follow  the  Inheritance, 
Restrictions  on  Children,  and  Data  Control  rules.  Change  the  parent 
action  when  appropriate. 
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2. 3. 1.5  Outputs 

2. 3. 1.5.1  CRUD  Matrix  (completed)  (Figure  2. 3. 1.7-2) 
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2. 3. 1.6  Rules 


2. 3. 1.6.1  Inheritance 

The  Action  of  a  parent  process  on  an  Entity  must  be  performed  by  at 
least  one  of  the  children. 

2. 3. 1.6. 2  Restrictions  on  Children 

The  Actions  of  the  children  may  vary  from  the  Actions  of  the  parent 
but  are  constrained  as  follows: 

If  the  parent's  Action  is  Create,  the  children  may  Create,  Update  or 
Retrieve. 

If  the  parent's  Action  is  Update,  the  children  may  Update  or  Retrieve. 

If  the  parents'  Action  is  Read,  the  children  may  Read. 

If  the  parent's  Action  is  Archive,  the  children  may  Update,  Read,  or 
Archive. 


2. 3. 1.6. 3  Data  Control 

For  each  level,  one  and  only  one  Process  can  create  an  Entity 
occurence. 

For  each  level,  one  and  only  one  Process  can  delete  an  Entity 
occurence. 
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2. 3. 1.7  Examples 

Figure  2. 3. 1.7-1  Sample  CRUD  (empty  cells  for  current  decomposition 

level 

Figure  2. 3. 1.7-2  Sample  CRUD  (completed  cells  for  current 

decomposition  level 
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Figure  2. 3. 1.7-1  Sample  CRUD 
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Figure  2.3. 1.7-2  Sample  CRUD 
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2.3.1  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 


2.3.1  DEVELOP  CRUD  MATRIX 

2. 3. 1.1  PURPOSE 

2. 3. 1.2  COMPONENTS/TERMS 

2. 3. 1.3  INPUT  PRODUCTS 

2. 3. 1.4  GENERAL  PROCEDURES 

2. 3. 1.4.1  DEVELOP  CRUD  MATRIX 

2. 3. 1.4. 1.1  LOGON  TO  PLANNING  WORKBENCH 

2. 3. 1.4. 1.2  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  'ASSOCIATION 
MATRIX' 

2. 3. 1.4. 1.3  SELECT  'PROCESS'  IN  THE  TOP  PORTION  OF  THE  DIALOGUE  BOX 

2. 3. 1.4. 1.4  SELECT  'BY  ENTITY  TYPE'  IN  THE  BOTTOM  PORTION  OF  THE 
DIALOGUE  BOX  AND  CLICK  ON  THE  'PROCEED'  RADIO  BUTTON 

2. 3. 1.4. 1.5  TO  DISPLAY  A  PARTICULAR  SET  OF  PROPERTIES 

2. 3. 1.4. 1.5.1  PULL  DOWN  THE  'ASSOCIATION  MATRIX'  MENU  AND  SELECT 
'SHOW  PROPERTIES' 

2. 3. 1.4. 1.5. 2  SELECT  THE  TYPE  OF  PROPERTIES  YOU  WISH  DISPLAYED 
('ACTION'  FOR  'CRUD'  PROPERTIES  OR  'LIFE  CYCLE  STAGE' 
FOR  LIFE  CYCLE  SEQUENCES) 

2. 3. 1.4. 1.6  TO  CHANGE  A  PROPERTY  (ADD,  MODIFY,  OR  ERASE) 

2. 3. 1.4. 1.6.1  CLICK  ON  THE  BOX  AT  THE  JUNCTION  OF  THE  PROCESS  AND 
ENTITY  WHOSE  RELATIONSHIP  ENGENDERS  THE  PROPERTIES  YOU 
WISH  TO  CHANGE 

2. 3. 1.4. 1.6. 2  TYPE  IN  THE  PROPERTIES  THAT  CORRECTLY  DESCRIBE  THE 
RELATIONSHIP  OF  THE  GIVEN  PROCESS  AND  ENTITY  (ENTER 
BLANKS  TO  WIPE  OUT  AN  EXISTING  PROPERTY) 
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2.3.1  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 

2.3.1  DEVELOP  CRUD  MATRIX 

Reference  Appendix  D,  GENERAL  PC  DICTIONARY  PROCEDURES,  for  more 
details  on  how  to  ADD,  EDIT,  DELETE,  COPY,  RENAME,  REPORT,  or  QUERY 
dictionary  members. 

2.3. 1.1  PURPOSE 

The  purpose  of  these  PC  Dictionary  procedures  is  to  explain  how  to 
capture  and  report  the  information  that  is  gathered  while  developing 
the  CRUD  matrix.  2. 3. 1.2  COMPONENTS/TERMS 

2. 3. 1.3  INPUT  PRODUCTS 


2. 3. 1.4  GENERAL  PROCEDURES 


2. 3. 1.4. 2  Identify  Actions  (Refer  to  IEW  CRUD  matrix) 


2. 3. 1.4. 2.1 

2. 3. 1.4. 2. 2 

2. 3. 1.4. 2. 3 

2. 3. 1.4. 2. 4 

2. 3. 1.4. 2. 5 

2. 3. 1.4. 2. 6 

2. 3. 1.4. 2. 7 

2. 3. 1.4. 2. 8 

2. 3. 1.4. 2. 9 

2.3.1.4.2.10 


Edit  existing  Process. 

Edit  SEE. 

Add  name  of  Entity  on  which  this  process  acts,  or  select 
from  F2  lookup  list. 

Edit  CLAUSE. 

Enter  the  text  FOR  CREATE/READ/UPDATE/DELETE  (only  the 
ones  that  apply  for  this  process  on  this  entity). 

Save  SEE. 

Repeat  for  each  Entity. 

Edit  any  other  attributes  as  needed. 

Save  Process. 

Repeat  for  each  process  with  action(s)  in  the  matrix. 
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2.3.2  DEVELOP  ENTITY  LIFE  CYCLE  MATRIX 


2. 3.2- 1 

2. 3. 2- 2 

2. 3. 2- 3 

2. 3.2.1 

2. 3. 2. 2 


2. 3. 2. 3 


2. 3. 2.4 


2. 3. 2. 5 


2. 3. 2. 6 


2. 3. 2. 7 


2.3.2  Appendix 
2.3.2  Appendix 


Step  Overview 
Step  Products 
Step  Comments 

Purpose 

Components 


2. 3. 2. 2.1  Entities 

2. 3. 2. 2. 2  Processes 

2. 3. 2. 2. 3  Entity  Life  Cycle  Sequence  Number 
Input  Products 

2. 3.2. 3.1  (empty)  Association  Matrix 

2. 3. 2. 3. 2  (completed)  CRUD  Matrix  for  current  level 
of  decomposition 

General  Procedures 


2. 3. 2. 4.1  Display  empty  Association  Matrix 

2. 3. 2. 4. 2  Identify  life  cycle  sequences 

Outputs 

2. 3.2. 5.1  Completed  Entity  Life  Cycle  Association 
Matrix 

Rules 


2. 3. 2. 6.1  Actions 

2. 3. 2. 6. 2  Inheritance 


Area  Examples 

Figure  2. 3. 2. 7-1  Empty  Association  Matrix  for  Current 

Level  of  Decomposition  (Contractor 
Profile  Subject  Area) 

Figure  2. 3. 2. 7-2  Completed  CRUD  for  Current  Level  of 

Decomposition  (Contractor  Profile 
Subject  Area) 

A  -  Detailed  IEW  Procedures 
B  -  Detailed  PC  Dictionary  Procedures 
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2.3.2  DEVELOP  ENTITY  LIFE  CYCLE  MATRIX 

2. 3. 2.1  Purpose 

To  validate  the  Logical  Functional  Architecture  (Processes)  by  assuring 
the  data  required  by  the  Processes  are  acquired  by  Processes.  The 
validation  is  accomplished  through  sequencing  processes  according  to 
the  life  cycle  of  Entities. 

2. 3. 2. 2  Components 

2. 3. 2. 2.1  Entities 

2. 3. 2. 2. 2  Processes 

2. 3. 2. 2. 3  Entity  Life  Cycle  Sequence  Number 

An  Entity  Life  Cycle  Sequence  Number  orders  processes  according  to  the 
life  cycle  of  an  Entity.  The  number  is  sequential. 
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2. 3. 2. 3  Input  Products 

2. 3. 2. 3.1  Association  Matrix  (empty)  (Figure  2. 3. 2. 7-1) 

2. 3. 2. 3. 2  CRUD  Matrix  (completed)  for  current  level  of  decomposition 
(Figure  2. 3. 2. 7-2) 
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2. 3. 2.4  General  Procedures 

2. 3. 2. 4.1  Display  empty  Association  Matrix 

Construct  a  Matrix  Diagram  with  Processes  for  the  rows  and  Entities  for 
the  columns.  The  cells  for  the  current  Global  Analyis  level  will  be 
blank.  Fill  in  the  Life  Cycle  Numbers  for  the  higher  levels  (parents, 
grandparents,  etc.). 

2. 3. 2. 4. 2  Identify  life  cycle  sequences 

For  each  entity,  number  the  processes  which  have  Actions  based  on  the 
life  cycle  of  that  entity.  Reference  the  CRUD  Matrix  when  sequencing 
the  processes.  Numbering  is  accomplished  by  entering  sequential 
numbers  to  arrange  processes  according  to  the  life  cycle  of  an  entity. 
The  intent  is  to  show  the  order  in  which  processes  acquire  (Create  or 
Update)  data  for  use  (Update  or  Read)  by  other  processes.  Reviewing 
the  sequence  may  point  out  error  conditions  requiring  correction.  Two 
general  error  conditions  are  data  use  without  acquisition  and  data 
acquisition  without  use. 
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2. 3. 2. 5  Outputs 

2. 3. 2. 5.1  Completed  Entity  Life  Cycle  Association  Matrix  (2. 3. 2. 7-3) 
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2. 3.2.6  Rules 

2. 3. 2. 6.1  Actions 

Only  processes  with  actions  are  sequenced.  Creates  will  be  first, 
Updates  and  Reads  may  be  interspersed,  and  Archives  are  last. 

2. 3. 2. 6. 2  Inheritance 

The  sequence  of  processing  at  one  level  cannot  conflict  with  the 
sequencing  at  a  higher  level. 
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2. 3. 2. 7  Examples 

Figure  2. 3. 2. 7-1  Empty  Association  Matrix  for  Current  Level  of 

Decomposition  (Contractor  Profile  Subject  Area) 

Figure  2. 3. 2. 7-2  Completed  CRUD  for  Current  Level  of  Decomposition 

(Contractor  Profile  Subject  Area) 

Figure  2. 3. 2. 7-3  Completed  Association  Matrix  for  Current  Level  of 

Decomposition  (Contractor  Profile  Subject  Area) 
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Figure  2. 3. 2. 7-1  Empty  Association  Matrix 
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Figure  2. 3. 2. 7-2  Completed  CRUD  for  Current  Level 


2.3.2  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 


2.3.2  DEVELOP  ENTITY  LIFE  CYCLE  MATRIX 

2.3.2. 1  PURPOSE 

2. 3. 2. 2  COMPONENTS/TERMS 

2. 3. 2. 3  INPUT  PRODUCTS 

2. 3. 2. 4  GENERAL  PROCEDURES 

2. 3.2.4. 1  DEVELOP  ENTITY  LIFE  CYCLE  MATRIX 

2. 3. 2. 4. 1.1  LOGON  TO  PLANNING  WORKBENCH 

2. 3. 2. 4. 1.2  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  'ASSOCIATION 
MATRIX' 

2. 3. 2. 4. 1.3  SELECT  'PROCESS'  IN  THE  TOP  PORTION  OF  THE  DIALOGUE  BOX 

2. 3. 2. 4. 1.4  SELECT  'BY  ENTITY  TYPE1  IN  THE  BOTTOM  PORTION  OF  THE 
DIALOGUE  BOX  AND  CLICK  ON  THE  'PROCEED'  RADIO  BUTTON 

2. 3. 2. 4. 1.5  TO  DISPLAY  A  PARTICULAR  SET  OF  PROPERTIES 

2. 3. 2. 4. 1.5.1  PULL  DOWN  THE  'ASSOCIATION  MATRIX*  MENU  AND  SELECT  'SHOW 
PROPERTIES' 

2. 3. 2. 4. 1.5. 2  SELECT  THE  TYPE  OF  PROPERTIES  YOU  WISH  DISPLAYED 
('ACTION'  FOR  'CRUD*  PROPERTIES  OR  'LIFE  CYCLE  STAGE' 

FOR  LIFE  CYCLE  SEQUENCES) 

2. 3. 2. 4. 1.6  TO  CHANGE  A  PROPERTY  (ADD,  MODIFY,  OR  ERASE) 

2. 3. 2. 4. 1.6.1  CLICK  ON  THE  BOX  AT  THE  JUNCTION  OF  THE  PROCESS  AND 
ENTITY  WHOSE  RELATIONSHIP  ENGENDERS  THE  PROPERTIES  YOU 
WISH  TO  CHANGE 

2. 3. 2. 4. 1.6. 2  TYPE  IN  THE  PROPERTIES  THAT  CORRECTLY  DESCRIBE  THE 
RELATIONSHIP  OF  THE  GIVEN  PROCESS  AND  ENTITY  (ENTER 
BLANKS  TO  WIPE  OUT  AN  EXISTING  PROPERTY) 
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2.3.2  APPENDIX  B  DETAILED  PC  DICTIONARY  PROCEDURES 

2.3.2  DEVELOP  ENTITY  LIFE  CYCLE  MATRIX 

Reference  Appendix  D,  GENERAL  PC  DICTIONARY  PROCEDURES,  for  more 
details  on  how  to  ADD,  EDIT,  DELETE,  COPY,  RENAME,  REPORT,  or  QUERY 
dictionary  members. 

2. 3. 2.1  PURPOSE 

The  purpose  of  these  PC  Dictionary  procedures  is  to  explain  how  to 
capture  and  report  the  information  that  is  gathered  while  developing 
the  entity  life  cycle  matrix. 

2. 3. 2. 2  COMPONENTS/TERMS 

2. 3. 2. 3  INPUT  PRODUCTS 


2. 3. 2. 4  GENERAL  PROCEDURES 


2. 3. 2. 4. 2  Identify  Life  Cycle  Sequences  (Refer  to  IEW  life  cycle 
matrix.) 


2. 3. 2. 4. 2.1 

2. 3. 2. 4. 2. 2 

2. 3. 2. 4. 2. 3 
2. 3. 2. 4. 2. 5 


2. 3. 2. 4. 2. 6 

2. 3. 2. 4. 2. 7 

2. 3. 2. 4. 2. 8 

2. 3. 2. 4. 2. 9 

2.3.2.4.2.10 


Edit  existing  Process. 

Edit  SEE. 

Edit  CLAUSE. 

Edit  the  text  FOR  CREATE/READ/UPDATE/DELETE  (only  the  ones 
that  apply  for  this  process  on  this  entity)  to  include  the 
life  cycle  sequence  number. 

Save  SEE. 

Repeat  for  each  Entity. 

Edit  any  other  attributes  as  needed. 

Save  Process. 

Repeat  for  each  process  with  sequences(s)  in  the  matrix. 
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2.4  REVIEW  SCOPE 

In  this  step  the  components  of  the  Functional  and  Data  Architecture 
which  are  in-scope  are  identified  by  applying  the  scoping  criteria 
(i.e.,  the  objectives  and  the  information  requirements).  Those 
processes  which  are  out-of-scope  are  "marked"  with  an  and  are  not 
further  decomposed.  Entities  which  are  out-of-scope  are  noted  for 
later  inclusion  in  a  scoping  memorandum. 
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2.4.1  SELECT  ENTITIES 


Figure  2.4. 1-1  Step  Overview 
Figure  2.4. 1-2  Step  Products 
Figure  2.4. 1-3  Step  Components 

2. 4. 1.1  Purpose 

2. 4. 1.2  Component/Terms 

2. 4. 1.2.1  Entity  Type 

2. 4. 1.2. 2  Information  Requirement 

2. 4. 1.3  Input  Products 

2. 4. 1.3.1  Subject  Area  Information  Requirements 

2. 4. 1.3. 2  Subject  Area  Entity  Relationship  Disagra 

2. 4. 1.3. 3  Subject  Area  Entity  Type  List 

2. 4. 1.3. 4  Subject  Area  Entity  Type  Report 

2.4. 1.4  General  Procedures 

2. 4. 1.4.1  Examine  Entity  Types 

2. 4. 1.4. 2  Review  scope 

2. 4. 1.4. 3  Update  Existing  Entity  Types 

2.4. 1.4.4  Add  new  Entity  Types,  if  needed 

2. 4. 1.4. 5  Update  ERD 

2. 4. 1.5  Output  Products 

2. 4. 1.5.1  Subject  Area  ERD 

2. 4. 1.5. 2  Subject  Area  Entity  Type  List 

2. 4. 1.5. 3  Subject  Area  Entity  Type  Report 

2. 4. 1.6  Rules 

2. 4. 1.6.1  Adherence  to  scoping  criteria 

2. 4. 1.6. 2  True  Entity  Type 

2. 4. 1.7  Examples 

Figure  2. 4. 1.7-1  Subject  Area  ERD 

Figure  2. 4. 1.7-2  Subject  Area  Entity  Type  List 

2.4.1  Appendix  A  -  Detailed  IEW  Procedures 

2.4.1  Appendix  B  -  Detailed  PC  Dictionary  Procedures 
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FIGURE  24.1-2 
STEP  PRODUCTS 
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FIGURE  2.4.1 -3 
STEP  COMPONENTS 
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2.4.1  SELECT  ENTITIES 


2. 4. 1.1  Purpose 

The  purpose  of  this  step  is  to  examine  the  Entity  types  that  have  been 
discussed  during  the  current  level  of  Global  Analysis  and  decide  which 
are  within  the  scope,  which  need  to  be  brought  into  scope  and  which 
need  to  be  deleted  from  the  scope.  This  will  identify  which  entity 
types  need  to  be  fully  attributed  and  which  will  only  be  needed  for  a 
reference  to  another  subject  area. 
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2. 4. 1.2  Components/Terms 

Following  are  the  components  and/or  terms  that  will  be  used  during  this 
step  of  Global  Analysis. 

2. 4. 1.2.1  Entity  Type 

2. 4. 1.2. 2  Information  Requirement 
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2. 4. 1.3  Input  Products 

2.4. 1.3.1  Subject  Area  Information  Requirements 

This  report  will  define  the  Subject  Area  Information  Requirements  as 
identified  in  1.1  Define  Scoping  Criteria.  (See  OUTPUT  PRODUCTS  from 
1.1) 


2. 4. 1.3. 2  Subject  Area  Entity  Relationship  Diagram  (ERD) 

This  diagram  contains  the  entity  types  that  were  identified  during 
Scoping.  (See  OUTPUT  PRODUCTS  from  1.2) 

2.4. 1.3.3  Subject  Area  Entity  Type  List 

This  list  will  contain  the  entity  types  that  were  identified  during 
Scoping.  (See  OUTPUT  PRODUCTS  from  1.2) 

2. 4. 1.3. 4  Subject  Area  Entity  Type  Report 

This  report  describes  the  entity  types  that  were  identified  during 
Scoping.  (See  OUTPUT  PRODUCTS  from  1.2) 
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2. 4. 1.4  General  Procedures 

2. 4. 1.4.1  Examine  Entity  Types 

Review  all  the  entity  types  that  have  been  discussed  during  the  current 
level  of  Global  Analysis.  Identify  which  are  'true'  entity  types  by 
comparing  the  meaning  of  an  Entity  type  to  the  current  definition  of 
each  entity  type. 

2.4. 1.4.2  Review  scope 

Decide  which  of  the  entity  types  are  within  the  scope  by  comparing  the 
Subject  Area  Information  Requirements  that  were  defined  in  1.2  Define 
Scoping  Criteria  with  the  entity  type  definitions.  Will  information 
about  a  particular  entity  type  be  necessary  to  satisfy  one  of  the 
Information  Requirements?  If  the  answer  is  yes,  then  that  entity  type 
is  within  scope. 

2. 4. 1.4. 3  Update  Existing  Entity  Types 

Identify  the  Entity  types  that  were  not  selected  during  the  Scoping 
phase,  but  which  are  now  within  the  scope.  Also  identify  the  Entity 
types  that  were  selected  during  the  Scoping  phase,  but  which  are  now 
not  within  the  scope.  These  are  identified  through  the  cataloging 
feature  of  the  dictionary.  Make  any  other  needed  changes  to  the 
existing  entity  types,  such  as  modifying  the  definitions. 

2. 4. 1.4. 4  Add  new  Entity  Types,  if  needed 

Add  any  new  entity  types  that  are  now  needed  for  further  analysis. 

These  entity  types  are  ones  that  never  existed  in  the  Conceptual  Model. 
Provide  proper  definitions  and  names  for  each. 

2. 4. 1.4. 5  Update  ERD 

Add  the  new  entity  types  to  the  ERD  with  appropriate  relationships  to 
the  other  entity  types  that  are  within  scope.  These  relationships  are 
unlabeled;  they  only  represent  that  a  relationship  exists. 
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2. 4. 1.5  Output  Products 

2. 4. 1.5.1  Subject  Area  ERD  (Figure  2. 4. 1.7-1) 

This  ERD  will  show  all  the  entity  types  and  the  generic  relationships 
between  entity  types  that  are  now  within  scope. 

2. 4. 1.5. 2  Subject  Area  Entity  Type  List  (Figure  2. 4. 1.7-2) 

This  list  will  contain  the  entity  types  that  are  now  within  scope. 

2. 4. 1.5. 3  Subject  Area  Entity  Type  Report  (reference  Figure  2. 1.7-2) 
This  report  describes  the  entity  types  that  are  now  within  scope. 


I 
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2. 4. 1.6  Rules 

2. 4. 1.6.1  Adherence  to  scoping  criteria 

All  chosen  entity  types  must  pertain  to  the  Information  Requirements 
established  in  1.1  Define  Scoping  Criteria. 

2. 4. 1.6. 2  True  Entity  Type 

An  Entity  is  defined  as  a  person,  place,  or  thing  that  is  (a)  of 
interest  to  the  corporation,  (b)  capable  of  being  described  in  real 
terms,  and  (c)  relevant  within  the  context  of  the  specific  environment 
of  the  firm.  An  entity  type  is  a  set  of  these  persons,  places,  or 
things,  all  of  which  have  a  common  name,  a  common  definition,  and  a 
common  set  of  descriptors  (properties  or  attributes),  (i.e.  EMPLOYEE  is 
the  entity  type:  JOHM  SMITH,  MARY  WILSON,  and  JOHN  DOE  are  entity 
occurrences  for  the  EMPLOYEE  entity  type.) 
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2. 4. 1.7  Examples 


Figure  2. 4. 1.7-1  Subject  Area  ERD 

Figure  2. 4. 1.7-2  Subject  Area  Entity  Type  List 
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Figure  2.4. 1.7-2  Subject  Area  Entity  Type  List 
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2.4.1  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 
2.4.1  SELECT  ENTITIES 

There  are  no  IEW  procedures  for  this  section. 
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2.4.1  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 


2.4.1  SELECT  ENTITIES 

Reference  Appendix  D,  GENERAL  PC  DICTIONARY  PROCEDURES,  for  more 
details  on  how  to  ADD,  EDIT,  DELETE,  COPY,  RENAME,  REPORT,  or  QUERY 
dictionary  members. 

2. 4. 1.1  PURPOSE 

The  purpose  in  these  PC  DICTIONARY  detailed  procedures  is  to  explain 
how  to  capture  and  report  the  information  that  is  gathered  while 
selecting  the  entities  that  will  be  further  analyzed. 

2. 4. 1.2  COMPONENT/TERMS 

2. 4. 1.3  INPUT  PRODUCTS 

See  1.0  Scoping  output  products. 

?. 4. 1.3.1  Subject  Area  Information  Requirements 

2. 4. 1.3. 2  Subject  Area  Entity  Relationship  Diagram  (ERD) 

2. 4. 1.3. 3  Subject  Area  Entity  List 

2. 4. 1.3. 4  Subject  Area  Entity  Report 

2.4. 1.4  GENERAL  PROCEDURES 

2. 4. 1.4.1  Examine  Entities 

2. 4. 1.4. 2  Review  scope 

2. 4. 1.4. 3  Update  Existing  Entities 

(Edit  Entities  that  are  now  within  scope) 

2. 4. 1.4. 3.1  Edit  each  existing  Entity  that  is  now  within  scope. 

2. 4. 1.4. 3. 2  Edit  the  CATALOG  attribute. 

2. 4. 1.4. 3. 3  Add  the  CATALOG  'CONTRACTOR  PROFILE'. 

2. 4. 1.4. 3. 4  Add  another  CATALOG  'ENTITY'. 

2. 4. 1.4. 3. 5  Save  CATALOGS. 

2.4. 1.4. 3. 6  Edit  any  other  attributes,  as  needed. 

2. 4. 1.4. 3. 7  Save  Entity. 

(Edit  Entities  that  are  not  now  within  scope) 

2. 4. 1.4. 3. 8  Edit  each  existing  Entity  that  is  now  not  within  scope. 

2. 4. 1.4. 3. 9  Edit  the  CATALOG  attribute. 

2.4.1.4.3.10  Delete  the  CATALOG  'CONTRACTOR  PROFILE'. 

2.4.1.4.3.11  Save  CATALOG. 

2.4.1.4.3.12  Edit  any  other  attributes,  as  needed. 

2.4.1.4.3.13  Save  Entity. 

2. 4. 1.4. 4  Add  new  Entities,  if  needed 

2. 4. 1.4. 4.1  Select  DATA  ENTRY  from  MAIN  MENU. 
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2.4. 1.4. 4. 2 


2. 4. 1.4. 4. 3 
[F2] . 

2. 4. 1.4. 4. 4 
details). 

2. 4. 1.4. 4. 5 

2. 4. 1.4. 4. 6 

2. 4. 1.4. 4. 7 

2. 4. 1.4. 4. 8 

2. 4. 1.4. 4. 9 


Enter  appropriate  name,  following  Naming  Conventions  found 
in  the  Appendix. 

Enter  appropriate  member  type  or  select  from  look  up  list 

Enter  necessary  attributes  (reference  Appendix  D  for  more 

Edit  the  CATALOG  attribute. 

Add  the  CATALOG  'CONTRACTOR  PROFILE1. 

Add  another  CATALOG  'ENTITY'. 

Save  CATALOGS. 

Save  new  member  [F10]. 


2.4. 1.4.5  Update  ERD 
See  IEW  Procedures. 


2.4. 1.5  OUTPUT  PRODUCTS 

2.4. 1.5.1  Subject  Area  ERD  (Figure  2. 4. 2. 7-1) 
See  IEW  Procedures. 


2. 4. 1.5. 2 


2. 4. 1.5. 2.1 

2. 4. 1.5. 2. 2 

2. 4. 1.5. 2. 3 


2. 4. 1.5. 2. 4 

2. 4. 1.5. 2. 5 


2. 4. 1.5. 2. 6 

2.4. 1.5. 2. 7 


2. 4. 1.5. 3 

2. 4. 1.5. 3.1 

2.4. 1.5. 3. 2 


2. 4. 1.5. 3. 3 

2. 4. 1.5. 3. 4 


Subject  Area  Entity  List  (Figure  2. 4. 2. 7-2) 

(Get  a  list  of  all  Entities  that  are  within  the  Subject 
Area) 

Select  CATALOGUE  from  QUERY  MENU. 

Select  query  logic,  EQUAL. 

Enter  catalogue  name,  CONTRACTOR  PROFILE,  or  select  from 
look  up  list  [F2]. 

Select  query  logic,  EQUAL. 

Enter  catalogue  name,  ENTITY,  or  select  from  look  up  list 
[F2] . 

Check  report  destination  [ALT-F10]. 

Start  query  [F10] . 

Subject  Area  Entity  Report  (Figure  2.4. 2. 7-3) 

(Get  report  of  Entities) 

Select  MEMBER  DEFINITION  from  REPORT  MENU. 

Select  the  names  of  all  Entities  [SPACE  BAR]  on  the 
previous  CATALOG  query  list. 

Check  report  destination  [ALT-F10] . 

Print  report  [F10-G0]. 
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2.4.2  SELECT  PROCESSES 


Figure  2. 4. 2-1  Step  Overview 
Figure  2. 4. 2-2  Step  Products 
Figure  2. 4. 2-3  Step  Components 

2.4.2. 1  Purpose 

2. 4. 2. 2  Components/Terms 

2. 4. 2. 2.1  Process 

2. 4. 2. 2. 2  Action 

2. 4. 2. 2. 2.1  Create 

2. 4. 2. 2. 2. 2  Retrieve 

2. 4. 2. 2. 2. 3  Update 

2. 4. 2. 2. 2. 4  Delete 

2. 4. 2. 3  Input  Products 

2. 4. 2. 3.1  CIA  CRUD  Association  Matrix 

2. 4. 2. 3. 2  Objectives  Report 

2. 4. 2. 3. 3  Information  Requirements  Report 

2. 4. 2. 4  General  Procedures 

2. 4. 2. 4.1  Review  CRUD  Association  Matrix 

2. 4. 2. 4. 2  Indicate  Out-of-scope  Processes 

2. 4. 2. 4. 3  Review  Subject  Area  Processes 

2. 4. 2. 5  Output  Products 

2.4. 2. 5.1  LIA  Process  CRUD  Association  Matrix 

2. 4. 2. 5. 2  LIA  Process  Reports 

2. 4. 2. 6  Rules 

2. 4. 2. 6.1  Adherence  to  scoping  criteria 

2. 4. 2. 6. 2  Mutual  exclusivity 

2. 4. 2. 6. 3  Exhaustiveness 

2. 4. 2. 6. 4  Naming  conventions  and  definitions 

2.4.2. 7  Examples 

Figure  2. 4. 2. 7-1  IEW  LIA  CRUD  Association  Matrix  (Two 

Levels  of  Processes) 

Figure  2.4.2. 7-2  IEW  Process  Report  (Process  AAA) 
Figure  2. 4. 2. 7-3  PCD  LIA  Process  List  (Two  Levels  of 

Processes) 

Figure  2. 4. 2. 7-4  PCD  Process  Report  (Function  A) 
Figure  2. 4. 2. 7-5  IEW  LIA  Process  CRUD  Association 
Matrix 

Figure  2. 4. 2. 7-6  IEW  LIA  Process  Report  (For  Process 

AAAA) 

Figure  2. 4. 2. 7-7  PCD  Process  Report  (For  Process  AAA) 
Figure  2. 4. 2. 7-8  Information  Requirements  Report 
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Figure  2. 4. 2. 7-9  Objectives  List 

2.4.2  Appendix  A  -  Detailed  IEW  Procedures 

2.4.2  Appendix  B  -  Detailed  PC  Dictionary  Procedures 
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2.4.2  SELECT  PROCESSES 
2.4.2. 1  Purpose 

The  purpose  of  this  step  is  to  apply  the  scoping  criteria  to  the  LIA 
(Logical  Information  Architecture)  processes  in  order  to  select  those 
processes  which  will  be  decomposed  and  analyzed  in  the  next  steps  of 
the  Global  Analysis  phase. 

The  reason  for  selecting  those  processes  which  are  within  scope  and  for 
excluding  those  which  are  out  of  scope  is  to  be  able  to  develop  a  set 
of  LIA  products  (diagrams,  reports,  and  documents)  which  contain  only 
those  components  which  are  involved  in  the  Subject  Area. 
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2. 4. 2. 2  Components/Terms 

2. 4. 2. 2.1  Process 

See  previous  definition. 

2. 4. 2. 2. 2  Action 

See  previous  definition. 

2. 4. 2. 2. 2.1  Create 

See  previous  definition. 

2. 4. 2. 2. 2. 2  Retrieve 
See  previous  definition. 

2. 4. 2. 2. 2. 3  Update 

See  previous  definition. 

2. 4. 2. 2. 2. 4  Delete 

See  previous  definition. 
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2. 4. 2. 3  Input  Products 

2. 4. 2. 3.1  CIA  CRUD  Association  Matrix 
See  previous  definition. 

2. 4. 2. 3. 2  Objectives  Report 
See  previous  definition 

2.4. 2. 3. 3  Information  Requirements  Report 
See  previous  definition. 


249 


2. 4. 2. 4  General  Procedures 

2. 4. 2. 4.1  Review  CRUD  Association  Matrix 

Identify  the  processes  in  the  rows  on  the  LIA  CRUD  Association  Matrix. 

Every  process  on  the  CRUD  Association  Matrix  should  have  the  actions 
of  its  subordinates  "rolled-up."  If  any  subordinate  processes  or 
processes  have  C,  R,  U,  and/or  D  indicated  for  an  entity,  then  the 
parent  should  also  have  the  CRUD  indicated  for  that  entity. 

2. 4. 2. 4. 2  Indicate  Out-of-scope  Processes 

It  is  assumed  that  the  entities  which  are  not  within  the  scope  of  the 
Subject  Area  have  been  deleted  from  the  LIA. 

It  is  also  assumed  that  all  processes  which  use  entities  are  properly 
indicated  with  C,  R,  U,  or  D  properties.  If  subordinate  processes  have 
CRUD  properties  then  the  parent  should  also  have  those  properties. 

Indicate  those  processes  within  the  CRUD  Association  Matrix  which  do 
not  use  the  entities  which  have  been  selected  as  being  within  the  scope 
of  the  subject  area;  indicate  those  processes  which  do  not  contain  any 
C,  R,  U,  or  D  in  their  rows  by  inserting  an  in  the  space  just  after 
the  process  sequence  number,  for  example:  AAA*ASSURE  ADEQUACY  OF 
PURCHASE  REQUEST. 

If  one  of  the  scoping  criteria  is  to  exclude  those  processes  which  do 
not  perform  specific  "actions"  ( e . g . ,  Create,  Retrieve,  Update,  or 
Delete),  then  also  indicate  those  processes. 

2. 4. 2. 4. 3  Review  Subject  Area  Processes 

Produce  reports  with  the  selected  subject  area  processes  and  their 
definitions.  Review  the  definitions  for  completeness  and  accuracy  while 
making  sure  that  the  processes  pertain  to  the  subject  area. 
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2.4. 2. 5  Output  Products 

2. 4. 2. 5.1  LIA  Process  CRUD  Association  Matrix 

2. 4. 2. 5. 2  LIA  Process  Reports 
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2. 4. 2. 6  Rules 

2. 4. 2. 6.1  Adherence  to  scoping  criteria 

n  order  to  stay  within  scope,  processes  must  follow  the  scoping 
criteria  (selected  objectives  and  information  requirements) 

2. 4. 2. 6. 2  Mutual  exclusivity 

All  processes  must  be  mutually  exclusive  at  the  same  level  of  their 
respective  hierarchy. 

2. 4. 2. 6. 3  Exhaustiveness 

All  processes  at  one  level  of  a  hierarchy  must  completely  exhaust  the 
parent. 

2. 4. 2. 6. 4  Naming  conventions  and  definitions 

All  processes  must  follow  the  component  definitions  and  naming 
conventions. 
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2.4. 2. 7  Examples 


Figure  2. 4. 2. 7-1 

Figure  2. 4. 2. 7-2 
Figure  2.4.2. 7-3 
Figure  2. 4. 2. 7-4 
Figure  2. 4. 2. 7-5 
Figure  2.4.2. 7-6 
Figure  2. 4. 2. 7-7 
Figure  2. 4. 2. 7-8 
Figure  2. 4. 2. 7-9 


IEW  LIA  CRUD  Association  Matrix  (Two  Levels  of 
Processes) 

IEW  Process  Report  (Process  AAA) 

PCD  LIA  Process  List  (Two  Levels  of  Processes) 
PCD  Process  Report  (Function  A) 

IEW  LIA  Process  CRUD  Association  Matrix 
IEW  LIA  Process  Report  (For  Process  AAAA) 

PCD  Process  Report  (For  Process  AAA) 
Information  Requirements  Report 
Objectives  List 
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Information  Engineering  Workbench  Report 
Object  Summary  Report 
July  3,  1990  16:48:55  NEWUSER  V06 

Process  AAA  ASSURE  ADEQUACY  OF  PR 

PROPERTIES: 

DEFINITION: 

ASSURE  ADEQUACY  OF  PURCHASE  REQUEST  (PR) 

CONSISTS  OF: 

A.  TRANSFORM  RECOMMENDED  BUY  INTO  A  PURCHASE  REQUEST 

B.  VALIDATE  THE  PR  FOR  ADMIN  COMPLETENESS 

C.  RESOLVE  INADEQUATE  PR'S 
(A  SUSPENDED  PR  WILL  EITHER  BE  REINSTATED  OR  CANCELLED) 

D.  MAKE  ADMINISTRATIVE  ASSIGNMENT  TO  BUYER 

E.  BEGIN  PROCUREMENT  ADMIN  LEAD  TIME  (PALT) 

F.  REINSTATE  OR  CANCEL  SUSPENDED  PRS 


Figure  2.4. 2. 7-2  IEW  Process  Report  (Process  AAA) 


255 


07/02/90 


DEFENSE  LOGISTICS  AGENCY 
Catalogue  Query 

The  following  members  satisfy  this  condition 
PROCESS  AND  CONTRACTOR  PROFILE. 


Member  Name 

Member  Type 

PR-APPLY-APPBL-EVALN-FACTR 

PROCESS 

PR-APPLY-EVALN-FACTR 

PROCESS 

PR-ASGN-RESP 

PROCESS 

PR-ASSUR-CONTR-CMPLC 

PROCESS 

PR-ASSUR-FINCL-CMPLC 

PROCESS 

PR-ASSUR-PRCH-RQST-ADQCY 

PROCESS 

PR-ASSUR-QLTY-SPLY-SVC 

PROCESS 

PR-ASSUR-TMLY-DLVY 

PROCESS 

PR-CLOSE-CONTR 

PROCESS 

PR-CLOSE-CONTR-FILE 

PROCESS 

PR-CNDCT-FINAL-OFFER-EVALN 

PROCESS 

PR-CNDCT-FLD-PRCNG 

PROCESS 

PR-CNDCT-FORML-AUDIT 

PROCESS 

PR-CNDCT- INTL-OFFER-EVALN 

PROCESS 

PR-CNDCT-POST-AWARD-MGT 

PROCESS 

PR-CNDCT-PRE-AWARD-SURVY 

PROCESS 

PR-CNDCT-PRICE-ANALS 

PROCESS 

PR-CNDCT-TECH-ANALS-COST-PROPL 

PROCESS 

PR-COMPR-BAFO-CNTRC-CBLTY 

PROCESS 

PR-COMPR-BAFO-CNTRC-PAST  PRFMC 

PROCESS 

PR-COMPR-BAFO-CONTR-REQMT 

PROCESS 

PR-COMPR-CBLTY-SRC-SLCTN-OFFER 

PROCESS 

PR-COMPR-GENRL-ADMNV-COST 

PROCESS 

PR-COMPR-MANFC -OH-COST 

PROCESS 
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DEFENSE  LOGISTICS  AGENCY 


07/02/90 

Member  Name 

PR-COMPR-PRFMC-SRC-SLCTN-OFFER 

PR-COMPR-PRPSD-ACTL-LABOR-RATE 

PR-COMPR-PRPSD-ACTL-MTL-COST 

PR-DEVLP-ACQST-STRTG 

PR-DTRM-COST-PRICE-ANALS-LEVEL 

PR-DTRM-OFRR-RPNTY 

PR-DTRM-RSPBL-OFRR 

PR-EVAL-BAFO 

PR-EVAL-CNTRC-HIST 

PR-EVAL-COST-PRICE-PROPL 

PR-EVAL-OFRR-CURR-CBLTY 

PR-EXAMN-DIR-COST-ELMNT 

PR-EXAMN-INDIR-COST-ELMNT 

PR-EXAMN-NGOTD-COND 

PR-EXEC-MOD 

PR-INVSG-DISCL 

PR-NOTFY-UNSFL-OFRR 

PR-PERFM-FINAL-OFFER-EVALN 

PR-PERFM-RVU 

PR-PREP-ACQST-PLAN 

PR-PREP-SOLCN 

PR-RVU-CNTRC-PRE-AWARD-SURVY 
PR-RVU-CONTR-PRFMC 
PR-RVU-FINCL-RATING  SVC 
PR-RVU-PRE-AWARD-CURVY-RCMDN 
PR-RVU-PRFMC-HIST 


Catalogue  Query- 
Member  Type 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 

PROCESS 


Pa 


I 
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07/02/90 
Member  Name 

PR-VERFY-PHYS- 
51  Member(s) 


Figure  2 


DEFENSE  LOGISTICS  AGENCY 
Catalogue  Query 
Member  Type 

CMPLN  PROCESS 


Satisfying  Catalogue  Query 


4  * 2 • 7-3  PCD  LIA  Process  List  (Two  Levels  of  Proc 
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07/02/90 
Member  Type 
Member  Name 


PROCESS 

PR-APPLY-APPBL 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 

Attribute  Name  &  Contents 


■EVALN-FACTR  ALIAS 

IEW  ABAD  APPLY  APPLICBL  EVAL  FACTORS 
CATALOGUE 

CONTRACTOR  PROFILE 
PROCESS 
DEFINITION 
DESCRIPTION 

ENTRY-CONTENT-APPROVER-ORG 
ENTRY-CONTENT -MAINTAINER-ORG 
FULL-NAME 

Apply  Applicable  Evaluation  Factor 
SOURCE 

DECOMPOSITION-TEXT 

PERFORMANCE 

RATE -OF -GROWTH 

SUGGESTED-MECHANISM 

CONTAINS 

PR-EVAL-SRC-SLCTN-OFFER 

PR-EVAL-QUOTN 

PR-EVAL-BID 


Figure  2. 4. 2. 7-4  PCD  Process  Report  (Function  A) 


Page  1 
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A  ACQUISITION  (F) 


AA  PURCHASE  REQ  PROCESSING  (F) 


B8  IP?  CAfCIOATE  ITEM  IDENT  (F) 


8C  PROO  PtAWING  SOD  OEV  (F) 


DEVELOP  IPP  PACKAGE  (F) 


OFFER 


LEGAL  EtfTTTY 


CONTRACT 


AS  OFFER  EVALUATION  (F) 

R 

RU 

CRU 

AC  CONTRACT  AWARD  (F) 

CRU 

CRU 

R  | 

AG  CONTRACT  ADMINISTRATION  (F) 

CRU 

CRU 

R 

A£  FORWARD  PRICE  RATE  DEV  (F) 

R 

CRU 

1 

AF  CONTRACTOR  SYSTEM  REVIEW  (F) 

CRU 

CRU 

mm 

B  INDUSTRIAL  PREP  FLAWING  (F) 

R 

DIM 

BA  MOBILIZATION  REO’fCNT  DET  (F) 

R 

RU 

Pracm  I  nvolvii  Entity  Typ« 


February  13.  1330  11:01:3? 


Figure  2. 4. 2. 7-5  IEW  LIA  Process  CRUD  Association  Matri 
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Information  Engineering  Workbench  Report 
Object  Summary  Report 
July  3,  1990  16:50:48  NEWUSER  V06 

Process  AAAA  TRANSFORM  REC  BUY  INTO  PR 

PROPERTIES: 

DEFINITION: 

TRANSFORM  RECOMMENDED  BUY  INTO  A  PURCHASE  REQUEST 
CONSISTS  OF: 

A.  ASSSIGN  PR  NUMBER 

B.  ESTABLISH  EFFECTIVE  DATE  OF  PR  (PART  OF  PR  NUMBER) 

C.  DEVELOP  TECHNICAL  PACKAGING  REQUIREMENTS 

D.  CREATE  A  PR  DOCUMENT  ( SF  36  CONTINUATION  SHEET) 

E.  CREATE  A  PR  RECORD  (SAMMS  -  CONTRACTING  SUBSYSTEM,  ACTIVE  PR  FIL 
( APRF ) 

F.  APPROVE  COMMITMENT  FUNDS 


Figure  2. 4. 2. 7-6  IEW  LIA  Process  Report  (for  Process  AAAA) 


07/02/90 
Member  Type 
Member  Name 


PROCESS 

PR-ASSUR-PRCH 


OEFENSE  LOGISTICS  AGENCY 

Member  Definition  Report  Page  1 

Attribute  Name  &  Contents 


•RQST-ADQCY  ALIAS 

IEW  AAA  ASSURE  ADEQUACY  OF  PR 
CATALOGUE 

CONTRACTOR  PROFILE 
LIFE  CYCLE  FUNCTION 
PROCESS 
DEFINITION 

Assure  Adequacy  of  Purchase  Request  contains  the  following  processes: 

1.  TO  TRANSFORM  A  RECOMMENDED  BUY  INTO  A  VEHICLE  FOR  SOLICITATION. 

2.  TO  VALIDATE  THE  PR  FOR  ADMIN  COMPLETENESS. 

3.  TO  ADDRESS  AND  RESOLVE  INADEQUATE  PRS.  A  SUSPENDED  PR  WILL  EITHER  BE 
REINSTATED  OR  CANCELLED. 

4.  TO  MAKE  ADMINISTRATIVE  ASSIGNMENT  TO  BUYER  BY  ASSIGNMENT  CRITERIA. 

5.  TO  BEGIN  PROCUREMENT  ADMIN  LEAD  TIME  (PALT). 

6.  TO  REINSTATE  OR  CANCEL  SUSPENDED  PRS. 

DESCRIPTION 

ENTRY-CONTENT-APPROVER-ORG 

ENTRY-CONTENT-MAINTAINER-ORG 

FULL-NAME 

ASSURE  ADEQUACY  OF  PR 
SOURCE 

DECOMPOSITION-TEXT 
PERFORMANCE 
RATE -OF -GROWTH 
SUGGESTED-MECHANISM 
CONTAINS 


Figure  2.4.2. 7-7 


PCD  Process  Report 


(For  Process  AAA) 
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07/02/90 
Member  Type 
Member  Name 


INFORMATION-REQUIREMENT 

IR-CNTRC-CONTR-PRFMC 


Figure 


DEFENSE  LOGISTICS  AGENCY 

Member  Definition  Report  Page  1 

Attribute  Name  &  Contents 


CATALOGUE 

CONTRACTOR  PROFILE 
INFORMATION  REQUIREMENT 
DEFINITION 

Information  which  indicates  a  given  contractor's  effectiveness  and 
efficiency  to  satisfy  contractual  obligations.  This  information 
indicates  performance  on  items,  performance  on  an  individual  contract, 
aggregate  performance  on  multiple  contracts,  or  performance  with  other 
Government  customers  and/or  non-Government  clients. 
ENTRY-CONTENT-APPROVER-ORG 
FULL-NAME 

Contractor  or  Contract  Performance 
SOURCE 

Team  member  knowledge 
CONTAINS 
EN-CONTR 

EN-ITEM 

EN-LEGAL-ENTY 

IR-0001 

IR-0002 

IR-0004 

IR-0010 

IR-0016 

IR-0017 

IR-0021 

IR-0022 

IR-0038 

IR -0040 

I R -0041 

IR-0045 

IR-0048 

•^•2.7-8  Information  Requirements  Report 
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07/02/90 
Heater  Type 
Member  Name 


OBJECTIVE 

OB-PROV-CNTRC 


DEFENSE  LOGISTICS  AGENCY 

Member  Definition  Report  Page  1 

Attribute  Name  &  Contents 


•PRFMC-DATA  CATALOGUE 

CONTRACTOR  PROFILE 
OBJECTIVE 
DEFINITION 

Provide  contractor  performance  data  in  order  to  award  contracts  to  the 
best  performing  contractors. 

ENTRY-CONTENT-APPROVER-ORG 

FULL-NAME 

Provide  Contractor  Performance  Data 
SOURCE 

Team  member  knowledge 


Figure  2.4.2. 7-9  Objectives  List 
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2.4.2  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 
2.4.2  SELECT  PROCESSES 

There  are  no  IEW  procedures  for  this  section. 
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2.4.2  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 

2.4.2  SELECT  PROCESSES 

Reference  Appendix  D,  GENERAL  PC  DICTIONARY  PROCEDURES,  for  more 
details  on  how  to  ADD,  EDIT,  DELETE,  COPY,  RENAME,  REPORT,  or  QUERY 
dictionary  members. 

2. 4. 2.1  PURPOSE 


The  purpose  of  these  PC  Dictionary  procedures  is  to  explain  how  to 
capture  and  report  the  information  that  is  gathered  while  selecting  the 
processes  that  will  be  further  analyzed. 

2. 4. 2. 2  COMPONENTS/TERMS 

2. 4. 2. 3  INPUT  PRODUCTS 

2. 4. 2. 4  GENERAL  PROCEDURES 


2. 4. 2. 4. 2 


2. 4. 2. 4. 2.1 

2. 4. 2. 4. 2. 2 

2. 4. 2. 4. 2. 3 

2. 4. 2. 4. 2. 4 

2. 4. 2. 4. 2. 5 

2. 4. 2. 4. 2. 6 

2. 4. 2. 4. 2. 7 

2. 4. 2. 4. 3 


2. 4. 2. 4. 3.1 

2. 4. 2. 4. 3. 2 

2. 4. 2. 4. 3. 3 

2. 4. 2. 4. 3.4 

2.4.2.4.3.5 


2. 4. 2. 4. 3. 6 


Indicate  Out-of-scope  Processes  (Refer  to  CRUD  matrix, 
namely  processes  identified  as  being  out  of  scope  with  the 
'*') 

Edit  one  out-of-scope  process. 

Edit  Catalog. 

Delete  CONTRACTOR  PROFILE  catalog. 

Save  catalog. 

Edit  any  other  attributes  as  needed. 

Save  process. 

Repeat  for  each  out-of -scope  process. 

Review  Subject  Area  Processes 
(Get  list  of  Subject  Area  Processes) 

Select  QUERY  from  MAIN  MENU. 

Select  CATALOGUE  from  QUERY  MENU. 

Enter  PROCESS  catalog  AND  CONTRACTOR  PROFILE  catalog. 

Run  report. 

(Get  report  of  Subject  Area  Processes) 

Use  previous  catalog  list  to  select  processes  for  the 
Member  Definition  report.  (Refer  to  Appendix  D  PC 
DICTIONARY  GENERAL  PROCEDURES  for  more  detail  on  the 
Member  Definition  report.) 

After  reviewing  the  definitions,  edit  processes  as  needed. 
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2.5  PREPARE  SCOPE  MEMORANDUM 


Figure  2.5-1  Step  Overview 
Figure  2.5-2  Step  Products 
Figure  2.5-3  Step  Components 


2.5.1  PURPOSE 

2.5.2  COMPONENTS 

2.5.2. 1  Objective 

2. 5. 2. 3  Information  Requirement 

2. 5. 2. 3  Entity 

2. 5. 2. 4  Process 

2.5.3  INPUT  PRODUCTS 

2. 5. 3.1  Subject  Area  Objective  Report 

2. 5. 3. 2  Subject  Area  Information  Requirements  Report 

2. 5. 3. 3  Subject  Area  Entity  Relationship  Diagram 

2. 5. 3.4  Subject  Area  Entity  Report 

2. 5. 3. 5  Subject  Area  Function  Decomposition  Diagram 

2. 5. 3. 6  Subject  Area  Function  Report 

2.5.4  GENERAL  PROCEDURES 

2.5.4. 1  Gather  Suppporting  Documentation 

2. 5. 4. 2  Prepare  DLA-IOM 

2.5.5  OUTPUT  PRODUCTS 

2. 5. 5.1  Subject  Area  Scope  IOM 

2.5.6  RULES 


2.5.7  EXAMPLES 


Figure  2. 5. 7-1 
Figure  2. 5. 7-2 

Figure  2. 5. 7-3 
Figure  2.5. 7-4 
Figure  2. 5. 7-5 

Figure  2. 5. 7-6 
Figure  2. 5. 7-7 


Subject  Area  Objective  Report 
Subject  Area  Information  Requirements 
Report 

Subject  Area  Entity  Relationship  Diagram 
Subject  Area  Entity  Report 
Subject  Area  Function  Decomposition 
Diagram 

Subject  Area  Function  Report 
Subject  Area  Scope  IOM 


2.5  Appendix  A  -  Detailed  IEW  Procedures 

2.5  Appendix  B  -  Detailed  PC  Dictionary  Procedures 
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ENTITY  RELATIONSHIP  DIAGRAM 
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2.5  PREPARE  SCOPE  MEMORANDUM 
2.5.1  PURPOSE 

To  document  the  scope  of  the  Subject  Area  for 

-  management  review  and  approval 

-  setting  the  proper  expectation 
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2.5.2  COMPONENTS 

2.5.2. 1  Objective 

2. 5. 2. 3  Information  Requirement 

2. 5. 2. 3  Entity 

2. 5. 2. 4  Process 
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2.5.3 

INPUT  PRODUCTS 

2. 5. 3.1 

Subject  Area 

2. 5. 3. 2 

Subject  Area 

2. 5. 3. 3 

Subject  Area 

2. 5. 3.4 

Subject  Area 

2. 5. 3. 5 

Subject  Area 

2. 5. 3. 6 

Subject  Area 

Objective  Report  (Figure  2.5. 7-1) 

Information  Requirements  Report  (Figure  2. 5. 7-2) 
Entity  Relationship  Diagram  (Figure  2. 5. 7-3) 
Entity  Reports  (Figure  2. 5. 7-4) 

Function  Decomposition  Diagram  (Figure  2. 5. 7-5) 
Function  Report  (Figure  2. 5. 7-6) 
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2.5.4  GENERAL  PROCEDURES 


2.5.4. 1  Gather  Suppporting  Documentation 

Gather  copies  of  the  products  listed  as  inputs.  These  will  be 
attachments  to  a  DLA  IOM  prepared  in  the  next  step.  These 
attachments  contain  the  Project  Team's  recommendation  on  scope. 

The  Project  Team  may  choose  to  also  gather  products  that  represent  the 
Conceptual  Architecture  so  that  what  is  in  scope  and  what  is  not  in 
scope  will  be  apparent. 

2. 5. 4. 2  Prepare  DLA-IOM 

An  IOM  is  prepared  that  explains  the  purpose  of  the  memo  and  the 
attachments.  The  memo  should  be  addressed  to  the  Program  Manager 
from  the  Team's  leader.  The  Program  Manager  will  coordinate  the  IOM 
for  comments,  review  meetings  and  ultimately  approval. 

The  memo  should  identify  the  scheduled  date  for  completing  Global 
Analysis.  Any  changes  to  scope  beyond  this  date  will  generally  result 
in  significant  rework  which  translates  into  cost  overruns  and 
slipped  schedules. 

After  completing  the  memo,  the  Team  will  be  expected  to  proceed 
directly  into  Global  Analysis  without  waiting  for  approval.  Changes 
received  during  Global  Analysis  will  require  the  Team  to  retrace 
Global  Analysis  steps. 
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2.5.5  OUTPUT  PRODUCTS 

2.5.5. 1  Subject  Area  Scope  IOM  (Figure  2. 5. 7-7) 
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2.5.6  RULES 
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2.5.7 

EXAMPLES 

Figure 

2. 5. 7-1 

Subject 

Figure 

2. 5. 7-2 

Subject 

figure 

2. 5. 7-3 

Subject 

Figure 

2. 5. 7-4 

Subject 

F igure 

2. 5. 7-5 

Subject 

Figure 

2. 5. 7-6 

Subject 

Figure 

2. 5. 7-7 

Subject 

Area  Objective  Report 

Area  Information  Requirements  Report 

Area  Entity  Relationship  Diagram 

Area  Entity  Report 

Area  Function  Decomposition  Diagram 

Area  Function  Report 

Area  Scope  IOM 
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07/02/90  Member  Definition  Report  Page  1 

Member  Type 

Member  Name  Attribute  Name  &  Contents 


OBJECTIVE 

OB-PROV-CNTRC-PRFMC-DATA  CATALOGUE 

CONTRACTOR  PROFILE 
OBJECTIVE 
DEFINITION 

Provide  contractor  performance  data  in  order  to  award  contracts  to  the 
best  performing  contractors. 

ENTRY-CONTENT -APPR0VER-0RG 
FULL -NAME 

Provide  Contractor  Performance  Data 
SOURCE 

Team  member  knowledge 


Figure  2. 5. 7-1  Subject  Area  Objective  Report 
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07/02/90 
Member  Type 
Member  Name 


INFORMATION-REQUIREMENT 

IR-CNTRC-CHARC 


INFORMATION-REQUIREMENT 

IR-CNTRC-CONTR-PRFMC 


DEFENSE  LOGISTICS  AGENCY 

Member  Definition  Report  Page  1 

Attribute  Name  &  Contents 


CATALOGUE 

CONTRACTOR  PROFILE 
INFORMATION  REQUIREMENT 
DEFINITION 

Information  which  identifies  and  describes  a  given  contractors  resources 
and  their  locations. 

ENTRY-CONTENT -APPRQVER-QRG 
FULL-NAME 

Contractor  Characteristics 
SOURCE 

Team  member  knowledge 
CONTAINS 
EN-ITEM 

EN-LEGAL-ENTY 

EN-OFFER 

IR-0021 

IR-0022 


CATALOGUE 

CONTRACTOR  PROFILE 
INFORMATION  REQUIREMENT 
DEFINITION 

Information  which  indicates  a  given  contractor's  effectiveness  and 
efficiency  to  satisfy  contractual  oDligations.  This  information 
indicates  performance  on  items,  performance  on  an  individual  contract, 
aggregate  performance  on  multiple  contracts,  or  performance  with  other 
Government  customers  and/or  non-Government  clients. 
ENTRY-CONTENT-APPROVER-ORG 
FULL-NAME 

Contractor  or  Contract  Performance 
SOURCE 

Team  member  knowledge 
CONTAINS 
EN-CONTR 

EN-ITEM 

EN-LEGAL-ENTY 

IR-0001 

IR -0002 
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07/02/90 
Member  Type 
Member  Name 

IR -0004 

IR-0010 

IR-0016 

IR-0017 

IR-0021 

IR-0022 

IR -0038 

IR-0040 

IR -0041 

IR-0045 

IR -0048 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 

Attribute  Name  &  Contents 


Figure  2. 5. 7-2  Subject  Area  Information  Requirements  Report 


Page  2 
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Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 


Page  1 


Attribute  Name  &  Contents 


ENTITY 

EN-CONTR  ALIAS 

CATALOGUE 
CONCEPTUAL 
CONTRACTOR  PROFILE 
ENTITY 
SUBSTANTIVE 
DEFINITION 

A  contract  is  a  mutually  binding  legal  instrument  obligating  the  seller 
to  furnish  the  supply,  service,  or  data  items  and  the  buyer  to  pay  for 
them. 

OESCR.PTIGN 

In  addition  to  bilateral  instruments,  contracts  include  (but  are  not 
limited  to)  job  orders  or  task  letters  issued  under  basic  order 
agreements;  letter  contracts;  orders,  such  as  purchase  orders,  under 
which  the  contract  becomes  effective  by  written  acceptance  or 
performance. 

ENTRY-CONTENT-APPROVER-ORG 
ENTRY-CONTENT-MAINTAINER-ORG 
FULL -NAME 
Contract 
SOURCE 

Team  member  knowledge 
FAR  suooart  2.1 
IDENTIFIER  IS 
CT-CONTR-NBR 
MULTI -ASSOCIATION  TO 
MULTI -ATTRIBUTES  ARE 
ONE-ASSOCIATION  TO 
ONE -ATTRIBUTES  ARE 
CT-CONTR-CLQSD-DATE 

CT-CONTR-DOLR-AMT 

CT-CONTR-EFCTV-AWARD-DATE 

CT-CONTR -PAYMT -TERM-TEXT 

CT-CONTR-DPAS-RATE-CD 

CT-CONTR- STAT- I NDCT 

CT-CONTR-OBGD-DOLR-AMT 

SEE 

SU8-ENnTIES  ARE 
EN-CONTR-MOD 

EN-CLAUS 

EN-SOW-ELMNT 
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Attribute  Name  &  Contents 


EN-LNITM 


ENTITY 

EN-LENTY  ALIAS 

CATALOGUE 
CONCEPTUAL 
CONTRACTOR  PROFILE 
ENTITY 
SUBSTANTIVE 
DEFINITION 

Legal  entity  is  a  person  or  group  of  persons,  a  corporation  or  other 
existence  recognized  by  law  as  having  rights  and  duties. 

DESCRIPTION 

This  includes  current  contractor,  past  contractor,  potential  contractor, 
or  offeror. 

ENTRY-CONTENT -APPR0VER-0RG 
ENTRY-CONTENT -MAI NTAI HER -ORG 
FULL-NAME 

LEGAL-ENTITY 

SOURCE 

Dictionary 

Team  member  knowleage 
IDENTIFIER  IS 
CT-LENTY-NBR 
MULTI -ASSOCIATION  T0 
MULTI -ATTRIBUTES  ARE 
CT-LENTY-FAX-NBR 

CT-LENTY-SIC-CD 

ct-lenty-tlphn-nbr 

ONE -ASSOCIATION  TO 
ONE -ATTRIBUTES  ARE 
CT-LENTY-8KRCY-CD 

CT-LENTY-BUSNS-SIZE 

CT-LENTY-OB-RATE-DATE 

CT-LENTY-NAME 

CT-LENTY-OWNSP-CD 

CT-LENTY-PARNi  ?DNTF 

CT-LENTY-STAT-CD 

CT-LENTY-TAX-ID-NBR 
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07/02/90 
Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 


Page  3 


Attribute  Name  &  Contents 

CT-LEN  iY-BlISNS-ADRS-TEXT 

CT-LENTY-OB-RATE-CD 

CT-LENTY-OISCL-STMT-STAT-INDCT 

CT -LENTY -ELGBY -ST AT - INDCT 

CT-LENTY-MALNG-ADRS-TEXT 

CT-LENTY-NOVTH-STAT -CD 

CT-LENTY-ASSN-CAGE-CD 

CT-LENTY-CAGE-CD 

CT-LENTY -WOMAN -OWNSP-IHDCT 

CT-LENTY-DI SAD- INDCT 

CT-LENTY-MNRTY-INDCT 

SEE 

EN-SRC 

EN-OFRR 

EN-CNTRC 

EN-SUB-CNTRC 

EN-PRE -AWD-SURVY -ROST 

EN-CAPBL 

EN-CNTRC-HIST 

EN-CNTRC-SYS 

EN-CNTRC-CORTV-ACTN 

EN-CONTR-QLTY-ASRNC 

EN-FINOG 

EN-FWD-PRICE-RATE 

EN-PRCDR-EVAL 

EN-PRCDR-RVU 
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Attribute  Name  &  Contents 


EN -QLTY -DATA-EVAL 

EN-SRVLC 

EN-CONTR 

FOR  "ASSOCIATION" 
EN-ITEM 

FOR  "ASSOCIATION" 
EN-OFFER 

FOR  "ASSOCIATION" 
EN-SOLCN 

FOR  "ASSOCIATION" 
SUB-ENTITIES  ARE 
EN-LENTY-CBLTY 

EN-LENTY-PRFMC-PLACE 

EN-LENTY-SYS-RVU 


Figure  2. 5. 7-4 


Subject  Area  Entity 


Report 
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DEFENSE  LOGISTICS  AGENCY 
07/02/90  Member  Definition  Report 
Member  Type 

Member  Name  Attribute  Name  &  Contents 


FUNCTION 

FN-ACQST  ALIAS 

I EH  A  ACQUISITION  (F) 

CATALOGUE 

FUNCTION 

LIFE  CYCLE  FUNCTION 
DEFINITION 

THIS  FUNCTION  EXISTS  FOR  THE  FOLLOWING  PURPOSES: 

1.  TO  PROCESS  PURCHASE  REQUESTS. 

2.  TO  EVALUATE  OFFERS. 

3.  TO  AWARD  CONTRACTS. 

4.  TO  ADMINISTER  CONTRACTS. 

5.  TO  DEVELOP  FORWARD  PRICE  RATE. 

6.  TO  REVIEW  CONTRACTOR  SYSTEM. 

DESCRIPTION 

ENTRY-CONTENT-APPROVER-ORG 

ENTRY-CONTENT-MAINTAINER-QRG 

FULL-NAME 

ACQUISITION 

SOURCE 

DECOMPOSITION-TEXT 

CONTAINS 

SEE 

FN-4-0-CONTR 
FOR  "BAA  FUNCTION" 

FN-5-O-CONTR-ADMIN 
FOR  "BAA  FUNCTION" 


Figure  2. 5. 7-6 


Subject  Area  Function  Report 


Page  1 
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CONTRACTOR  PROFILE  PILOT  THAN. 


SUBJECT:  Memorandum  of  Scoping  for  Logical  Information  Architecture 
(Contractor  Profile  Pilot) 


TO:  DSMO-PK 

ATTN :  LTC  Mike  Hedges ,  Program  Manager 


1.  Reference:  Logical  Information  Architecture  (1LA)  Developmen 
Procedures  Draft,  February  1990,  Section  1.4  (enclosure  1,  P RE PAR 
SCOPE  MEMORANDUM) . 

2.  Purocse:  The  ourocses  of  the  Scoping  Phase  cf  the  LIA. 
Development  Procedures  include  the  following: 


a.  To  develop  the  scoping 
cut  of  the  Conceptual  Informer, 
analyzed  and  designed  during  t 
Development  Phase.  The  scopin' 
Requirements  (IP's)  and  Object 
Logical  Design. 


3.  Explanation  cf  attachments: 

The  following  steps  were  performed  to  produce  the  attachments 
(products)  required  to  complete  the  Scoping  Phase: 

a.  The  Pilot  team  reviewed  the  Conceptual  Information 
Architecture  (CIA)  (enclosure  2,  CIA  ASSOCIATION  MATRIX) .  This 
matrix  shows  the  conceptual  entities,  functions  and  processes  wi 
constitute  the  entire  CIA.. 

b.  Identified,  collected  and  reviewed  source  documents 
(enclosure  3,  LIST  CF  SCOPING  SOURCE  DOCUMENTS). 
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CONTRACTOR  PROFILE  PILOT  TEAM  PAGE  2 

SUBJECT:  Memorandum  of  Scoping  for  Logical  Information  Architecture 


c.  Defined  detailed  Information  Requirements  (IR's)  (enclosure 
4 ,  DETAILED  INFORMATION  REQUIREMENTS ) . 

d.  Defined  high-level  Information  Requirements  (enclosure  5, 
HIGH-LEVEL  INFORMATION  REQUIREMENTS ) . 

e.  Defined  the  Objective  of  the  Contractor  Profile  Subject  Area 
(enclosure  6,  OBJECTIVE  OF  THE  CONTRACTOR  PROFILE  SUBJECT  AREA). 

f.  Applied  the  scoping  criteria  to  the  Conceptual  Data 
Architecture  and  selected  the  conceptual  entities  which  are  within 
the  scooe  of  the  Logical  Data  Architecture  (enclosure  7,  CONCEPTUAL 
ENTITY  RELATIONSHIP  DIAGRAM,  enclosure  8,  SELECTED  ENTITY 
RELATIONSHIP  DIAGRAM,  enclosure  9,  SELECTED  ENTITY  REPORT). 

g.  Applied  the  scoping  criteria  to  the  Conceptual  Functional 
Architecture  and  selected  the  functions  which  are  within  the  scope 
cf  the  Logical  Functional  Architecture,  (enclosure  10,  CONCEPTUAL, 
FUNCTION  TO  ENTITY  ASSOCIA.TION  MATRIX ,  enclosure  11,  SELECTED 
FUNCTION  TO  ENTITY  .ASSOCIATION  MATRIX ,  enclosure  12,  SELECTED 
FUNCTION  REPORT). 

4 .  Recommendations : 

a.  The  Pilot  Team  recommends  that  the  objective  cf  the 
Contractor  Profile  Pilot  Logical  Information  Architecture  be  as 
follows : 

"Provide  contractor  performance  data  in  order  to  award  contracts  to 
the  best  performing  contractors.” 

b.  The  Pilot  team  recommends  that  the  high  level  information 
requirements  to  be  fulfilled  by  the  Contractor  Profile  Pilot  are  as 
follows : 

(1)  Contract  or  Contractor  Performance 

” Information  which  indicates  a  given  contractor's  effectiveness  and 
efficiency  to  satisfy  contractual  obligations.  This  information 
indicates  performance  on  items,  performance  on  an  individual 
contract,  aggregate  performance  on  multiple  contracts,  or 
performance  with  other  Government  customers  and,  or  non-Government 
clients  .  " 

(2)  Contractor  Capability 

"Information  which  identifies  and  describes  a  contractor's  ability 
and  capacity  to  provide  a  service  or  a  product." 
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CONTRACTOR  PROFILE  PILOT  TEAM  PAGE  3 

SUBJECT:  Memorandum  of  Scoping  for  Logical  Information  Architecture 


( 3 )  Contractor  Characteristics 

“Information  which  identifies  and  describes  a  given  contractor's 
resources  and  its  location ( s ) . " 

(4)  Information  Requirements  not  to  be  included 
(definitions  listed  in  enclosure  13). 

(a)  Bids  and  Proposals 

(b)  Contract  Requirements 

(c)  Item 

(d)  Government  Performance 

c.  The  Pilot  team  has  applied  the  scoping  criteria  according  to 
the  scoping  procedures,  selecred  the  entities,  and  recommends  that 
the  following  entities  (as  defined  in  enclosure  9,  SELECTED  ENTITY 
REPORT)  be  included  within  the  scope  of  the  Logical  Data 

Arch"  -u0C"tiTji'r‘o  z 

( 1 )  Legal  Entirv 

( 2 )  Contract 

(3)  Offer 

(4)  Item 

The  following  entities  are  nor  within  the  scope  of  the  Contractor 
Profile  Pilot  Logical  Information  Architecture  because  they  do  net 
contain  attributes  relative  to  the  selected  contractor  performance, 
capability  and  characteristics  Information  Requirements  and 
Objective.  Entities  net  included  are  as  follows  (definitions  listed 
in  enclosure  14): 

( 5 )  Employee 

( 6 )  Solicitation 

(7)  Organization 

( 8 )  Funds 

(9)  Purchase  Request 

(10)  Customer 

d.  The  Pilot  team  has  applied  the  scoping  criteria,  selected 
functions  according  to  the  scoping  procedures  and  recommends  that 
the  following  functions  (described  in  enclosure  12,  SELECTED 
FUNCTION  REPORT)  be  included  within  the  scope  of  the  Logical 
Functional  Architecture : 

(1)  Purchase  Request  Processing 

(2)  Offer  Evaluation 
(  3  )  Contract  Award 

(4)  Contract  Administration 


COTRACTOR 

SUBJECT: 


PROFILE  PILOT  TEAM  .  ,  . * 

Memorandum  of  Scoping  for  Logical  Information  Architecture 


(5) 

(5) 

(7) 

(8) 

Evaluation 

(9) 

(10) 


Forward  Price  Rate  Development 
Contractor  System  Review 

Mobilization  Reauirement  Determination 

Industrial  Preparedness  Planning  (IPP)  Candidate  Item 


Production  Planning  Schedule  Development 
IPP  Package  Development 


5  The  scheduled  date  for  the  completion  of 
Logical  Information  Architecture  Development 
is ~30  March  1990. 


the  next  phase  of  the 
( i . e . ,  Global  Analysis) 


Francis  C.  Bruno 
Team  Leader 
DLA-AP 


Team  Members 

DLA-C  (J-  Faust) 
DLA-P  (J.  Pic tt ) 
DLA-Q  (D.  Fuller 
DLA-Q  (?.  wells ) 


Figure  2. 5. 7-7  Subject  Area  Scope  IOM 
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2.5  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 

2.5  PREPARE  SCOPE  MEMORANDUM 

There  are  no  IEW  procedures  for  this  section. 
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2.5  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 
2.5  PREPARE  SCOPE  MEMORANDUM 

There  are  no  PC  Dictionary  procedures  for  this  section. 
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3  UNIT  ANALYSIS 


In  this  level  the  lowest  level  process,  which  is  within  scope  (i.e., 
the  Sequential  Process),  is  further  defined  and  related  to  the  Data 
Architecture.  Each  Sequential  Process  is  defined  in  Action  Diagrams 
which  contain  the  conditional  logic  and  algorithms  for  performance  of 
the  process.  The  Action  Diagrams  are  mapped  to  the  Data  Architecture 
via  Information  Views.  These  data  views  define  the  entities  and 
attributes  which  are  used  (i.e.,  entered,  processed,  and  output  by 
each  Sequential  Process).  Additionally,  the  detailed  attribute 
descriptions  are  developed  for  entry  into  the  data  dictionary. 
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3.1  DEVELOP  INFORMATION  VIEWS 


Figure  3.1-1  Step  Overview 
Figure  3.1-2  Step  Products 
Figure  3.1-3  Step  Components 

3.1.1  PURPOSE 

3.1.2  COMPONENTS/TERMS 

3. 1.2.1  Information  Views 

3. 1.2. 2  Entity  View 

3. 1.2. 3  Entity  Type  Description 

3. 1.2. 4  Leaf  Process 

3. 1.2. 5  Subject  Area  ERD 

3.1.3  INPUT  PRODUCTS 

3. 1.3.1  List  of  Leaf  Processes 

3. 1.3. 2  Definitions  of  Leaf  Processes 

3. 1.3. 3  List  of  Entity  Types  and  their  Attributes 

3. 1.3. 4  LIA  Entity  Relationship  Diagram  (ERD) 

3. 1.3. 5  Definitions  of  Entity  Types 

3. 1.3. 6  CRUD  Association  Matrix 

3.1.4  GENERAL  PROCEDURES 

3. 1.4.1  Identify  Entities  in  the  Entity  View 

3. 1.4. 2  Identify  the  Attributes  in  the  Entity  Description 

3. 1.4. 3  Identify  Entity  Relationships  for  the  Entity  View 

3.1.5  OUTPUT  PRODUCTS 

3. 1.5.1  An  Entity  View  for  each  Leaf  Process 

3. 1.5. 2  An  Entity  Type  Description  for  each  Entity  Type  in  an 
Entity  View 

3.1.6  RULES 

3. 1.6.1  Information  Views 

3. 1.6. 2  Entity  Descriptions 

3. 1.6. 3  Attributes 

3.1.7  EXAMPLES 

Figure  3. 1.7-1  List  of  Leaf  Processes 

Figure  3. 1.7-2  Definitions  of  Leaf  Processes 

Figure  3. 1.7-3  List  of  Entity  Types  and  their  Attributes 

Figure  3. 1.7-4  LIA  Entity  Relationship  Diagram  (ERD) 

Figure  3. 1.7-5  Definitions  of  Entity  Types 
Figure  3. 1.7-6  CRUD  Association  Matrix 

3.1  Appendix  A  -  Detailed  IEW  Procedures 

3.1  Appendix  B  -  Detailed  PC  Dictionary  Procedures 
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FIGURE  3.1-2 
STEP  PRODUCTS 
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ATTRIBUTE  DESCRIPTIONS 


FIGURE  3.1-3 
STEP  COMPONENTS 


3.1  DEVELOP  INFORMATION  VIEWS 


3.1.1  PURPOSE 

Information  Views  map  the  Data  and  Functional  Architectures  at  the 
lowest  level  of  these  Architectures.  Information  Views  validate  the 
Data  Architecture  by  assuring  that  the  data  required  by  a  process 
exists  in  the  data  model  and  by  assuring  the  data  affected  by  a 
process  exists  in  the  model.  Information  Views  validate  the 
Functional  Architecture  by  assuring  that  the  processes  exist  for 
producing  the  data  required. 
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3.1.2  COMPONENTS/TERMS 

3. 1.2.1  Information  Views 

An  Information  View  is  made  up  of  an  Entity  View  and  one  or  more 
Entity  Type  Descriptions.  The  Entity  View  identifies  the  Entity  Types 
used  by  a  Leaf  Process  ( i . e . ,  the  Entity  Types  upon  which  the  process 
takes  action  (i.e.,  Create,  Retrieve,  Update,  or  Delete)).  The  Entity 
Type  Description  identifies  the  Attributes  of  interest  for  an 
individual  Entity  Type  in  an  Entity  View.  There  must  be  an  Entity 
Type  Description  for  each  Entity  Type  in  an  Information  View.  An 
Information  View  is  made  up  of  two  components:  Entity  View  and  Entity 
Type  Descriptions. 

3. 1.2. 2  Entity  View 

The  Entity  View  identifies  the  Entity  Types  used  by  a  Leaf  Process 
(i.e.,  the  Entity  Types  upon  which  the  process  takes  action  (i.e., 
Create,  Retrieve,  Update,  or  Delete)).  The  Entity  View  also 
identifies  the  Entity  Relationships  needed  for  the  process.  The  view 
is  represented  in  the  form  of  an  Entity  Relationship  Diagram  (ERD).  In 
effect,  the  Entity  View  is  what  the  Subject  Area  ERD  looks  like  to  a 
process. 


3. 1.2.3  Entity  Type  Description 

The  Entity  Type  Description  identifies  the  Attributes  of  interest  for 
an  individual  Entity  Type  in  an  Entity  View.  There  must  be  an  Entity 
Type  Description  for  each  Entity  Type  in  an  Information  View. 

3. 1.2. 4  Leaf  Process 

3. 1.2. 5  Subject  Area  ERD 


300 


3.1.3  INPUT  PRODUCTS 

3. 1.3.1  List  of  Leaf  Processes  (Figure  3. 1.7-1) 

3. 1.3. 2  Definitions  of  Leaf  Processes  (Figure  3. 1.7-2) 

3. 1.3. 3  List  of  Entity  Types  and  their  Attributes  (Figure  3. 1.7-3) 

3. 1.3. 4  LIA  Entity  Relationship  Diagram  (ERD)  (Figure  3. 1.7-4) 

3. 1.3. 5  Definitions  of  Entity  Types  (Figure  3. 1.7-5) 

3. 1.3. 6  CRUD  Association  Matrix  (Figure  3. 1.7-6) 
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3.1.4  GENERAL  PROCEDURES 


3. 1.4.1  Identify  Entities  in  the  Entity  View 

For  each  Leaf  Process,  identify  the  Entity  Types  that  will  be  in  the 
process's  Entity  View.  The  CRUD  Analysis  Report  is  used  to  identify 
the  Entity  Types  that  are  in  the  Entity  View.  Select  the  Entity  Types 
that  have  Actions  (Create,  Retrieve,  Update,  and  Archive). 

3. 1.4. 2  Identify  the  Attributes  in  the  Entity  Description 

For  each  Entity  Type  in  an  Entity  View  identify  the  Attributes  that 
are  used  by  the  Leaf  Process.  Review  the  list  of  Attributes  for  the 
Entity  and  select  those  that  are  needed  for  each  action  on  the  Entity 
(e.g.,  if  there  is  a  Retrieve,  identify  the  attributes  that  are 
Retrieved.)  Next,  write  down  any  attributes  that  are  missing  by 
asking  the  question,  does  all  the  data  required  for  the  action  exist? 
Examine  the  definition  of  a  Process  when  identifying  the  attributes  to 
assure  an  understanding  of  the  Process.  Review  the  definition  of  an 
Entity  before  marking  down  missing  attributes.  Look  at  related 
Entities  for  missing  attributes. 

3. 1.4. 3  Identify  Entity  Relationships  for  the  Entity  View 

Compare  the  Entity  Type  Descriptions  of  each  Entity  to  the  Entity  Type 
Descriptions  of  all  other  Entity  Type  Description  in  the  Entity  View. 
Use  this  comparison  along  with  the  Subject  Area  ERD  to  identify  the 
Relationships  required  in  the  Entity  View. 
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3.1.5  OUTPUT  PRODUCTS 

3. 1.5.1  An  Entity  View  for  each  Leaf  Process 

3. 1.5. 2  An  Entity  Type  Description  for  each  Entity  Type  in  an  Entity 
View 
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3.1.6  RULES 


3. 1.6.1  Information  Views 

Each  Leaf  Process  must  have  an  Information  View.  That  is  each  process 
must  have  a  requirement  for  Subject  Area  data. 

3. 1.6.2  Entity  Descriptions 

Each  Entity  Type  in  an  Entity  View  must  have  an  Entity  Description 
with  one  exception.  When  an  Entity  Type  is  archived  by  a  process,  the 
Output  View  shall  contain  the  Entity  Type  without  a  corresponding 
Entity  Description. 

3. 1.6. 3  Attributes 

Each  Entity  Type  Description  must  contain  at  least  one  Attribute. 
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3.1.7 

Figure 

Figure 

Figure 

Figure 

Figure 

Figure 


EXAMPLES 

3. 1.7- 1  List  of  Leaf  Processes 

3. 1.7- 2  Definitions  of  Leaf  Processes 

3. 1.7- 3  List  of  Entity  Types  and  their  Attributes 

3. 1.7- 4  LIA  Entity  Relationship  Diagram  (ERD) 

3. 1.7- 5  Definitions  of  Entity  Types 

3. 1.7- 6  CRUD  Association  Matrix 
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Information  Engineering  Workbench  Report 
Object  List 

July  3,  1990  15:02:22  NEWUSER  CPVERC1 


Page 


ABAC+DET  LVL  OF  COST  PRICE  ANLS 
ABADB+COMPARE  CAP  TO  OFFER 
ABAFA+REV  HIST  PAS  FOR  OFFEROR 
ABAFB+REV  PREV  CONTRACT  PERF 
ABAFC+REV  DUN&BRAD  FIN  REPORT 
ABBC+ PERFORM  PAS  REVIEWS 
ABBCA+CONDUCT  TECHNICAL-  PAS 
ABBCB+CONDUCT  PRODUCTION  PAS 
ABBCC+CONDUCT  QUALITY  PAS 
ABBCD+CONDUCT  FINANCIAL  PAS 
AJ3BCE-r CONDUCT  ACCOUNT  SYS  PAS 
A3BCF+C0NDUCT  GOVT  PROP  CTL  PAS 
ABBCG+CONDUCT  TRANSPORTATION  PAS 
ABBCH-rCONDUCT  PACKAGING  PAS 
A3BCJ-C0ND  PLNT  SFTY  PAS/EXPLSVS 
A3CC-CRT  PRE  NEG  3RF  MEMO 
A3DCDA-C0KPARE  BAJFO  TO  REQMNTS 
A3DCD3+C0MPARE  BAFO  TO  KTR  CAB 
ABDD-DET  IF  OFFEROR  RESPONSIBLE 
ADAAAA+REVIEW  CONT  PERF  HIST 
ADBBC-PERFORM  PRODUCTION  SRVLNCE 
ADBCA^ INSTRUCT  QA  REP 
ADBCBC-PROOF  ADQUCY  OF  KTR  PROCS 
ADBCBDA+CONDUCT  PRODUCT  AUDITS 
ADBCBDB-rCOLLECT  DATA  AND  ANALYZE 
ADBCBE+PROCESS  CORRECTIVE  ACTION 
ADBCC+EVAL  FRST  ARTCL  TST  REP 
ADBCDBB-rEVAL  KTR  CHANGE  '  REQUEST 
ADBCE+TEST  SPARE /REPAIR  PARTS 
ADBCFB+ INVEST  DEFICS  /  CMPLNT3 
ADBDC+ASSURE  CMPLNC  PROG  PMNTS 
ADBEA+ ASSURE  GOVT  PROP  CMPLIANCE 
ADBEB+ASSURE  TRANS /PKG  CMPLIANCE 
ADBED+ASSURE  SAFETY  COMPLIANCE 
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Figure  3.  1.7-1  List  of  Leaf  Processes 


None 


lABADB+COHPARE  CAP  TO  OFFER 


Transaction  Center 

jj  (Y.  N  ) 

Central  Transform 

U  <Y' N  ) 


Definition 


(COMPARE  OFFERORS'  CAPABILITY  TO  PERFORM  TO  THE  SOURCE  SELECTION  OFFERS 

I 

j 

i 

[THIS  IS  A  SEQUENTIAL  PROCESS 


Comments 


Lost  Saved 

1990/05/30  14:05  NEldUSER 
Lost  Update 

1990/05/23  14:01  NEUUSER 
Created 

1990/04/29  10:51:02  NEUUSER 


ABA08-C0MPARE  cap  to  offer 


July  3.  1990  15:09  2  A 


Figure  3. 1.7-2  Definition  of  Leaf  Process 
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Information  Engineering  Workbench  Report 
Object  Summary  Report 

July  3,  1990  15:08:42  NEWUSER  CPVER01 

Entity  Type  CLAUS 
PROPERTIES : 

PURPOSE:  FUNDAMENTAL 

LAST  UPDATE:  1990/06/20  07:22  NEWUSER 

CREATED:  1990/04/23  08:05:10  NEWUSER 

COMMENTS : 

Fullname  -  Clause 

ASSOCIATIONS: 

is-part-of 

Entity  Type  CONTR 
identifies 

Entity  Type  FUND-ACCT 
is-contained-in 

Entity  Tyne  SOLCN 
IS  INVOLVED  IN 

Subject  Area  SA-CONTRACT-ROOT 
Subject  Area  SA-CLAUSE-ROCT 
Subject  Area  SA-CLAUS E-TYPE 

Sequential  Process  A3ADB-COKPARE  CAP  TO  OFFER 
Sequential  Process  ABBC -PERFORM  PAS  REVIEWS 
Sequential  Process  ABDD-DET  IF  OFFEROR  RESPONSIBLE 
Sequential  Process  ABCC^CRT  PRE  NEG  BRF  MEMO 
Sequential  Process  ABBCA^CONDUCT  TECHNICAL  PAS 
Sequential  Process  ABBCC-CONDUCT  QUALITY  PAS 
Sequential  Process  ABBCH+CONDUCT  PACKAGING  PAS 
Sequential  Process  ABBCG+CONDUCT  TRANSPORTATION  PAS 
Sequential  Process  ABBCB+CONDUCT  PRODUCTION  PAS 
Sequential  Process  ADBBC+PERFORM  PRODUCTION  SRv  _iNCE 
Sequential  Process  ABDCDA+COMPARE  BAFO  TO  REQMNTS 
Sequential  Process  ADBDC4- ASSURE  CMPLNC  PROG  PMNTS 
Sequential  Process  ADBCC+EVAL  FRST  ARTCL  TST  REP 
Sequential  Process  ABDCDB+COMPARE  BAFO  TO  KTR  CAP 
Sequential  Process  ADBCA+ INSTRUCT  QA  REP 
Sequential  Process  ADBCBDA+CONDUCT  PRODUCT  AUDITS 
Sequential  Process  ADBCBDB+COLLECT  DATA  AND  ANALYZE 
Sequential  Process  ADBCBE+PROCESS  CORRECTIVE  ACTION 
Sequential  Process  ADBCE+TEST  SPARE/REPAIR  PARTS 
Sequential  Process  ADBCDBB+EVAL  KTR  CHANGE  REQUEST 
Sequential  Process  ABBCF+CONDUCT  GOVT  PROP  CTL  PAS 
Sequential  Process  ADBEA+ ASSURE  GOVT  PROP  CMPLIANCE 
Sequential  Process  ABBCJ+COND  PLNT  SFTY  PAS/EXPLSVS 
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Sequential  Process  ADBED+ ASSURE  SAFETY  COMPLIANCE 
Subject  Area  SA-FUND-ACCOUNT-ROOT 
Subject  Area  SA-SOLICITATION 
Subject  Area  IN-SCOPE 
is-classif ied-by 

Entity  Type  CLAUS -TYPE 
IS  DESCRIBED  BY 

Attribute  Type  NBR 
Attribute  Type  FAR-REF-NBR 
Attribute  Type  DSCRN-TEXT 
IS  IMPLEMENTED  BY 

Local  Data  Structure  CLAUS 

Local  Data  Structure  CLAUS . FAR-REF-NBR 

Local  Data  Structure  CLAUS . is -part-of . CONTR 

Local  Data  Structure  CLAUS . identifies . FUND-ACCT 

Local  Data  Structure  CLAUS . is -conrained-in . SOLCN 


Entity  Type  ITEM 
PROPERTIES: 

PURPOSE:  FUNDAMENTAL 

LAST  UPDATE:  1990/06/20  07:22  NEWUSER 


CREATED:  1989/06/16  10:27:09  NEWUSER 


DEFINITION: 

AN  ITEM  IS  A  SUPPLY  OR  SERVICE  THAT  HAS  BEEN  OR  WILL  BE  ACQUIRED  TO 
FULFILL  A  GOVERNMENT  REQUIREMENT. 

COMMENTS : 

AUDIT  TRAIL:  ITEM  INCLUDES  ACCEPTANCE,  ACQUISITION  PLAN,  CORRECTIVE 
ACTION,  COST/PRICE  PROPOSAL,  FEDERAL  SUPPLY  CLASS,  INDUSTRIAL 
PREPAREDNESS  PLANNING,  INVENTORY,  ITEM  HISTORY,  ITEM  REQUIREMENT, 
LOCATION,  OPERATING  SCENARIO,  PRODUCT,  PRODUCT  VERIFICATION  INSPECTI 
PRODUCTION  PLANNING  SCHEDULE,  PROPERTY,  ROUTE,  WEAPONS  SYSTEM, AND 
MATERIEL. 

ASSOCIATIONS: 

IS  REQUESTED  BY 

Entity  Type  SOLCN 
is-procured-by 

Entity  Type  GOVAG 
is-supplied-by 

Entity  Type  GOVAG 
is-maintained-by 
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Entity  Type  GOVAG 
is-examined-by 

Entity  Type  LAB-TEST 
IS  INVOLVED  IN 

Subject  Area  SA- ITEM-FEDERAL-SUPPLY-CLASS 
Subject  Area  SA-ITEM-ROOT 
Subject  Area  SA-LINE-ITEM-ROOT 
Subject  Area  SA-LEGAL-ENTITY-PLACE-OF-PERFMC 
Sequential  Process  ABBC+PERFORM  PAS  REVIEWS 
Subject  Area  SA-LABORATORY-TEST-ROOT 
Sequential  Process  ABAC-rDET  LVL  OF  COST  PRICE  ANLS 
Seauential  Process  ABADB-COMPARE  CAP  TO  OFFER 
Sequential  Process  ABDD-rDET  IF  OFFEROR  RESPONSIBLE 
Seauential  Process  ABCC+CRT  PRE  NEG  BRF  MEMO 
Sequential  Process  ABBCA-CONDUCT  TECHNICAL  PAS 
Seauential  Process  ABBC3-rC0NDUCT  PRODUCTION  PAS 
Sequential  Process  ABBCC+CONDUCT  QUALITY  PAS 
Seauential  Process  ABBCG^-CONDUCT  TRANSPORTATION  PAS 
Sequential  Process  ABBCH+CONDUCT  PACKAGING  PAS 
Seauential  Process  ABBCJ^COND  PLNT  SFTY  PAS/EXPLSVS 
Seauential  Process  ADBBC-PERFORM  PRODUCTION  SRVLNCE 
Seauential  Process  ADBCC-EVAL  FRST  ARTCL  TST  REP 
Sequential  Process  ABDCDA-COMPARE  BAFO  TO  REQMNTS 
Sequential  Process  ABDCDB-COMPARE  BAFO  TO  KTR  CAP 
Sequential  Process  ADBCA- INSTRUCT  QA  REP 
Sequential  Process  ADBCBC-PROOF  ADQUCY  OF  KTR  PROCS 
Sequential  Process  ADBCBDA+CONDUCT  PRODUCT  AUDITS 
Sequential  Process  ADBCBDB-rCOLLECT  DATA  AND  ANALYZE 
Sequential  Process  ADBCBE+PROCESS  CORRECTIVE  ACTION 
Sequential  Process  ADBCE+TEST  SPARE/REPAIR  PARTS 
Sequential  Process  ADBCDBB+EVAL  KTR  CHANGE  REQUEST 
Sequential  Process  ADBCFB+ INVEST  DEFICS  /  CMPLNTS 
Sequential  Process  ADBEA-t-ASSURE  GOVT  PROP  CMPLIANCE 
Sequential  Process  ADBEB+ASSURE  TRANS/PKG  CMPLIANCE 
Sequential  Process  ADBED+ASSURE  SAFETY  COMPLIANCE 
Sequential  Process  ABBCF+CONDUCT  GOVT  PROP  CTL  PAS 
Subject  Area  SA-GOVERNMENT-AGENCY-ROOT 
Subject  Area  IN-SCOPE 

/ 

Entity  Type  OFFER 
IS  IDENTIFIED  BY 
Entity  Type  PR' 
is -associated -with 
Entity  Type  LNITM 
Entity  Type  LENTY-POP 
is -classified -by 

Entity  Type  ITEM-FSC 
IS  DESCRIBED  BY 
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Attribute  Type  APRV- SRC -NAME 
Attribute  Type  CMPLX-CD 
Attribute  Type  HAZ-MTL-INDCT 
Attribute  Type  MPR-PART-NBR 
Attribute  Type  NATL-STF-NBR 
Attribute  Type ' DSCRN-TEXT 
IS  IMPLEMENTED* BY 

Local  Data  Structure  ITEM 

Local  Data  Structure  is-associated-with . ITEM 
Local  Data  Structure  ITEM. APRV- SRC -NAME 
Local  Data  Structure  ITEM. MPR-PART-NBR 
Local  Data  Structure  ITEM. is-procured-by .GOVAG 
Local  Data  Structure  ITEM. is -supplied-by .GOVAG 
Local  Data  Structure  is-associated-with . ITEM 
Local  Data  Structure  examines . ITEM 

Entity  Type  LENTY 

PROPERTIES : 

PURPOSE:  FUNDAMENTAL 

LAST  UPDATE:  1990/06/20  CT:22  NEWUSER 
CREATED:  1990/04/23  08:17:14  NEWUSER 
COMMENTS : 

Pullname  -  Legal  Entity 

ASSOCIATIONS: 

is -evaluated -by 

Entity  Type  PRFMC 
is -identified -by 

Entity  Type  ALERT -ACTN 

has 

Entity  Type  DEFCN 
receives 

Entity  Type  PRFMC-RCGTN 
responds -to 

Entity  Type  SOLCN 
submits 

Entity  Type  OFFER 

has 

Entity  Type  LENTY-SRV 
IS  INVOLVED  IN 

Subject  Area  SA-DEFICIENCY-ROOT 
Subject  Area  SA-OFFER-ROOT 

Figure  3. 1.7-3  List  of  Entity  Types  and  their  Attributes 
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AO-CONT  ft  - RO  LC 


07/02/90 
Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 


Page  1 


Attribute  Name  &  Contents 


ENTITY 

EN-CONTR  ALIAS 

CATALOGUE 
CONCEPTUAL 
CONTRACTOR  PROFILE 
ENTITY 
SUBSTANTIVE 
DEFINITION 

A  contract  is  a  mutually  binding  legal  instrument  obligating  the  seller 
to  furnish  the  supply,  service,  or  data  items  and  the  buyer  to  pay  for 
them. 

DESCRIPTION 

In  addition  to  bilateral  instruments,  contracts  include  (but  are  not 
limited  to)  job  orders  or  task  letters  issued  under  basic  order 
agreements;  letter  contracts;  orders,  such  as  purchase  orders,  under 
which  the  contract  becomes  effective  by  written  acceptance  or 
performance. 

ENTRY-CONTENT-APPROVER-ORG 

ENTRY-CONTENT-MAINTAINER-ORG 

FULL-NAME 

Contract 

SOURCE 

Team  member  knowledge 
FAR  subpart  2.1 
IDENTIFIER  IS 
CT-CONTR-NBR 
MULTI -ASSOCIATION  TO 
MULTI -ATTRIBUTES  ARE 
ONE -ASSOCIATION  TO 
ONE -ATTRIBUTES  ARE 
CT-CONTR-CLOSO-OATE 

CT-C0NTR-00LR-AMT 

CT-CONTR-EFCTV-AWARD-DATE 

CT-CONTR-PAYMT-TERM-TEXT 

CT-CONTR-DPAS-RATE-CD 

CT-CONTR-STAT-INDCT 

CT-C0NTR-0BGD-00LR-AMT 

SEE 

SUB-ENTITIES  ARE 
EN-CONTR -MOO 

EN-CLAUS 

EN-SOW-ELMNT 


313 


07/02/90 
Member  Type 
Member  Name 


DEFENSE  LOGISTICS  AGENCY 
Member  Definition  Report 


Attribute  Name  &  Contents 


EN-LNITM 


Figure  3. 1.7-5  Definitions  of  Entitv  Types 
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|  OFFER 
LEGAL  E.VTTTY 


contract 


aacxjisition  (F) 

CRU 

CRU 

R  | 

M  PU?CHASE  REQ  PROCESSING  (F) 

R 

R 

j 

AB  OFFER  EVALUATION  (F) 

R 

RU 

CRU  jj 

AC  CONTRACT  WARD  (F) 

CRU 

CRU 

R 

AO  CONTRACT  ADMINISTRATION  (F) 

CRU 

CRU  1  R 

AE  FGRUARO  PRICE  RATE  DEV  (F) 

R 

CRU  j  i 

AF  CONTRACTOR  SYSTEM  REVIEW  (F) 

CRU 

CRU  I  | 

8  INDUSTRIAL  PRE?  FLAWING  (F) 

R 

RU  ! 

SA  MOBILIZATION  REO’MENT  DET  (F) 

R 

RU  1 

■  38  IPP  CANDIDATE  ITEM  IDENT  (F) 

i  RU  i  ! 

'  BC  PRCO  PLANNING  SCK3  0£V  (F) 

RU 

’  30  DEVELOP  IPP  PACKAGE  (F) 

i  r  :  | 

P'  JCIII  I  nvol  vii  £  n  '  .  r  y  7  y  3  # 


f iBr aory  13.  3330  11:31:37 


Figure  3 . 1 . 7-6  CRUD  Association  Matrix 
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3.1  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 


3.1  DEVELOP  INFORMATION  VIEWS 

3.1.1  PURPOSE 

3.1.2  COMPONENTS/TERMS 

3.1.3  INPUT  PRODUCTS 

3.1.4  GENERAL  PROCEDURES 


3. 1.4.1  IDENTIFY  ENTITIES  IN  THE  ENTITY  VIEW 


3. 1.4. 1.1 

3. 1.4. 1.2 

3. 1.4. 1.3 

3. 1.4. 1.4 

3. 1.4. 1.5 

3. 1.4. 1.6 

3. 1.4. 1.7 


3. 1.4. 1.8 

3. 1.4. 1.9 


3.1.4.1.10 


3.1.4.1.11 


3.1.4.1.12 


LOGON  TO  THE  ANALYSIS  WORKBENCH 

PULL  DOWN  THE  'DISPLAY*  MENU  AND  SELECT  THE  'OBJECT  LIST' 
OPTION 

CLICK  ON  THE  'DESELECT  ALL'  RADIO  BUTTON 

SELECT  'SEQUENTIAL  PROCESSES'  WITHIN  THE  DIALOGUE  BOX  LIST 

CLICK  ON  THE  'PROCEED'  RADIO  BUTTON 

SELECT  THE  SEQUENTIAL  PROCESS  WHOSE  INFORMATION  VIEW  YOU 

WISH  TO  DEVELOP/MODIFY 

PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  THE  'ENTITY 
DIAGRAM'  OPTION  (NOTE:  DUE  TO  THE  PREVIOUS  EFFORT  TO 
DEVELOP  THE  CRUD  MATRIX,  THE  ENTITY  DIAGRAM  DISPLAYED 
SHOULD  CONTAIN  ONE  OR  MORE  ENTITIES  ALREADY  ASSOCIATED  WITH 
THE  GIVEN  PROCESS) 

MOVE  THE  ENTITY  DIAGRAM  WINDOW  TO  THE  TOP  OF  THE  SCREEN 
CLICK  THE  MOUSE  SOMEWHERE  WITHIN  THE  OBJECT  LIST  WINDOW  IN 
ORDER  TO  'ACTIVATE'  THAT  WINDOW 
PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  THE  'ACTION 
DIAGRAM'  OPTION  (NOTE:  REMEMBER,  THE  PROCESS  YOU  ARE 
WORKING  WITH  IS  STILL  SELECTED  IN  THE  OBJECT  LIST  WINDOW) 
ARRANGE  THE  ACTION  DIAGRAM  AND  ENTITY  DIAGRAM  WINDOWS  SUCH 
THAT  THE  ENTITY  DIAGRAM  IS  DISPLAYED  ACROSS  THE  ENTIRE  TOP 
OF  THE  SCREEN,  TAKING  UP  AS  LITTLE  SPACE  AS  POSSIBLE  WHILE 
REMAINING  LEGIBLE,  AND  THE  ACTION  DIAGRAM  IS  DISPLAYED 
ACROSS  THE  BOTTOM  OF  THE  SCREEN,  WITH  AS  MUCH  SPACE  AS 
POSSIBLE  (NOTE:  IT  IS  EXPECTED  THAT  THE  OBJECT  LIST  WILL 
THUS  BE  HIDDEN  BEHIND  THEM) 

REVIEW  THE  ACTION  DIAGRAM  AND. MODIFY  THE  ENTITY  DIAGRAM  AS 
NECESSARY  IN  ORDER  TO  ENSURE  THAT  ALL  ENTITIES  REQUIRED  BY 
THE  ACTION  DIAGRAM  ARE  PRESENT  WITHIN  THE  ENTITY  DIAGRAM 


3.1.4.1.12.1 


TO  ADD  AN  ENTITY  WITHIN  THE  ENTITY  DIAGRAM 


3.1.4.1.12.1.1 

3.1.4.1.12.1.2 

3.1.4.1.12.1.3 


PULL  DOWN  THE  'ADD'  MENU  AND  SELECT  THE  ENTITY 
OPTION 

CLICK  ON  THE  'FIND'  OPTION 

SELECT  THE  DESIRED  ENTITY  FROM  THE  LIST  THAT  WILL 
APPEAR  WITHIN  THE  DIALOGUE  BOX  AND  CLICK  ON  THE 
'PROCEED'  RADIO  BUTTON 


3.1.4.1.12.2 


TO  EXCLUDE  AN  ENTITY  FROM  THE  ENTITY  DIAGRAM 
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3.1.4.1.12.2.1  SELECT  THE  ENTITY  OR  ENTITIES  TO  BE  EXCLUDED 

3.1.4.1.12.2.2  PULL  DOWN  THE  'EDIT'  MENU  AND  SELECT  THE  'EXCLUDE' 
OPTION  (  I  M  P  0  R  T  A  N  T  !  -  DO  NOT  ACCIDENTALLY 
SELECT  THE  'DELETE'  OPTION  WHICH  WILL  BE  NEAR  THE 
'EXCLUDE'  OPTION  ON  THE  'EDIT'  MENU!  ) 

3. 1.4. 2  IDENTIFY  THE  ATTRIBUTES  IN  THE  ENTITY  DESCRIPTION 

3. 1.4. 2.1  PERFORM  STEPS  OUTLINED  IN  3. 1.4.1  ABOVE 

3. 1.4. 2. 2  IN  THE  ENTITY  DIAGRAM,  SELECT  THE  ENTITY  WHOSE  ATTRIBUTES 
YOU  WISH  TO  IDENTIFY 

3. 1.4. 2. 3  PULL  DOWN  THE  'DISPLAY*  MENU  AND  SELECT  THE  ‘ENTITY  TYPE 
DESCRIPTION'  OPTION 

3. 1.4. 2. 3.1  TO  ADD  ATTRIBUTES  TO  THE  ENTITY  VIEW 

3. 1.4. 2. 3. 1.1  PULL  DOWN  THE  'ADD'  MENU  AND  SELECT  THE  'ATTRIBUTE 
TYPE’  OPTION 

3. 1.4. 2. 3. 1.2  CLICK  THE  MOUSE  ON  THE  'FIND'  OPTION 

3. 1.4. 2. 3. 1.3  SELECT  THE  ATTRIBUTE  TYPE(S)  YOU  WISH  TO  ADD  (FROM 
WITHIN  THE  DIALOGUE  BOX  LIST  OF  ATTRIBUTES)  AND  CLICK 
ON  THE  'PROCEED'  RADIO  BUTTON 

3. 1.4. 2. 3. 2  TO  EXCLUDE  ATTRIBUTES  FROM  THE  ENTITY  VIEW 

3. 1.4. 2. 3. 2.1  SELECT  THE  ATTRIBUTE(S)  YOU  WISH  TO  EXCLUDE  FROM  THE 
VIEW 

3. 1.4. 2. 3. 2. 2  PULL  DOWN  THE  'EDIT'  MENU  AND  SELECT  THE  'EXCLUDE' 
OPTION  (  IMPORTANT!  -  DO  NOT  ACCIDENTALLY 
SELECT  THE  'DELETE'  OPTION  WHICH  WILL  BE  DISPLAYED 
NEAR  THE  'EXCLUDE'  OPTION  ON  THE  'EDIT'  MENU) 


3.1  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 
3.1  DEVELOP  INFORMATION  VIEWS 

There  are  no  PC  Dictionary  procedures  for  this  section 
Decisions  need  to  be  made  as  to  what  should  be  stored 
due  to  the  information  view  activity. 


at  this  time, 
in  PC  DICTIONARY 
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3.2  DEVELOP  ACTION  DIAGRAMS 


Figure  3.2-1  Step  Overview 
Figure  3.2-2  Step  Products 
Figure  3.2-3  Step  Components 

3.2.1  PURPOSE 

3.2.2  COMPONENTS/TERMS 

3.2.2. 1  Sequential  Processes 

3. 2. 2. 2  Action 

3. 2. 2. 3  Data  Access  or  Data  Store  Access 

3. 2. 2. 3  Exit 

3. 2. 2. 4  Repitition  Block 

3. 2. 2. 5  Selection  Block 

3.2.3  INPUT  PRODUCTS 

3.2.3. 1  Entity/Relationship  Diagram  with  Classification 
Entities 

3. 2. 3. 2  Process  Dependency  Diagrams 

3. 2. 3. 3  Detailed  Process  Descriptions 

3. 2. 3. 4  Process  Decomposition  Diagrams 

3. 2. 3. 5  Loqical  Information  Architecture  (LIA)  CRUD  Association 
Matrix 

3.2.4  GENERAL  PROCEDURES 

3.2.4. 1  Review  LIA  CRUD  Association  Matrix 

3. 2. 4. 2  Review  Process  Detail  Reports 

3. 2. 4. 3  Review  Process  Decomposition  Diagrams 

3. 2. 4. 4  Review  Process  Dependency  Diagrams 

3.2.4. 5  Develop  Action  Diagrams 

3.2.5  OUTPUT  PRODUCTS 

3. 2. 5.1  Action  Diagrams 

3.2.6  RULES 

3. 2. 6.1  Sequential  Process  Naming  Notations 

3. 2. 6. 1.1  Initial  Identification  of  Sequential 
Processes 

3. 2. 6. 1.2  Removal  of  Sequential  Process  Identification 

3. 2. 6. 1.2.1  Removal  of  Notation 

3. 2. 6. 1.2. 2  Return  Process  to  Full  Process 
Status 

3. 2. 6. 1.3  Final  Identification  of  Sequential  Processes 

3. 2. 6. 2  Data  Access  Conventions 
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3. 2. 6. 2.1  Entity  Reads 

3. 2. 6. 2. 1.1  Data  Description 

3. 2. 6. 2. 1.2  Multiple  Reads 

3. 2. 6. 3  Level  of  Detail 

3. 2. 6. 4  Embedded  Sequential  Processes 

3. 2. 6. 4.1  Multiple  Access  to  Individual  Embedded 
Sequential  Processes 

3. 2. 6. 4. 2  Dummy  Block  Notation 

3. 2. 6. 4. 3  Use  of  Keywords 


3.2.7  EXAMPLES 


Figure  3. 2. 7-1 

Figure  3. 2. 7-2 
Figure  3. 2. 7-3 
Figure  3.2. 7-4 
Figure  3. 2. 7-5 

Figure  3.2. 7-6 


Entity/Relationship  Diagram  with  Classification 
Entities 

Process  Dependency  Diagram 

Detailed  Process  Description 

Process  Decomposition  Diagram 

Logical  Information  Architecture  (LIA)  CRUD 

Association  Matrix 

Action  Diagram 


3.2  Appendix  A  -  Detailed  IEW  Procedures 

3.2  Appendix  B  -  Detailed  PC  Dictionary  Procedures 
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PRODUCTS 


COMPONENTS 


PROCESS 
DEPENDENCY 
a A Q PAM 

FUNCTION 
DCRNmON 
WE  PONT 

PROCESS 

DERATION 

report 


|  MAPS  | 

jpi-JS?? 

CRUD 
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A- 

MATRIX 

JK 

ACTION 

lit 

Pis 

DIAGRAM 

M 

m 

USER  VIEW/ 
SCREEN  LAYOUT 

j§ 

B 

DIAGRAM 

m 

DATA 

ARCHITECTURE 


entity  type 
OOHVnON 

REPORTS 


ATTWBUT1 

DCWWDOM 

REPORT 


ENTITY  TYPE 

ocacfimoN 

REPORT 


ATTWEUTE 

OE3CMPT10NS 


RELATION*!* 

DIAGRAM 


MW5RKATTOR 

VIEW 

DUGRAM 


BnTTY  VIEW 
DUGRAM 


PROCESS 

DEPENDENCIES 


MAPS 


PROCESS 

SEQUENCE 

MOMiCWS 

SCREEN  LASELS 


STANDARD 
OUTPUT  DATA 


CONTEXTUAL 
OUTPUT  DATA 


QUERY  CfWTOVA 


SCREEN 

FUNCTIONS/ 

COMMANDS 

PROCESS  MOOULt 
LM  (CAGES 


DATA 

ARCHITECTURE 


*11A'»0W9#PS 

ATTRISUTV9 


RGURE  12-1 
STEP  OVERVIEW 
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SCOPING 


FUNCTIONAL 

ARCHITECTURE 


MAPS 


DATA 

ARCH 
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3.2  DEVELOP  ACTION  DIAGRAMS 


3.2.1  PURPOSE 

Action  Diagrams  (AD 1 s )  describe  the  series  of  actions  that  compose  a 
sequential  process.  An  action  diagram  consists  of  a  sequence  of  steps 
to  follow  toward  some  purpose.  Each  step  consists  of  one  action  to 
perform,  a  group  of  actions  that  are  combined  to  form  a  block,  or 
another  sequential  process.  Brackets  identify  the  actions  included  in  a 
block,  each  of  which  is  a  complex  action;  a  nested  block  is  just  one 
more  action  to  perform.  Actions  execute  in  order  from  top  to  bottom. 
Conditions  on  the  blocks  determine  whether  the  block  is  executed,  and 
if  so,  how  often.  Individual  actions,  such  as  'CALCULATE  SUM  OF  ...', 
and  'NOTIFY  OFFEROR  OF  DECISION1  are  manually  typed  into  the  AD  in  the 
logically  proper  location  within  the  appropriate  block(s).  However, 
the  identification  of  'Create,  'R'ead,  'U'pdate,  and  'D'elete  actions 
(CRUD)  are  handled  in  a  special  manner,  and  are  accomplished  by 
utilizing  the  embedded  'ADD'  pull  down  menu  (DATA  STORE  OPERATION). 

Each  CRUD  Action  must  be  coupled  with  a  reference  to  an  entity  f^om  the 
Entity  Relationship  Diagram  (ERD),  to  the  right  of  which  will  be  an 
area  where  text  may  be  manually  entered  to  describe  the  data  to  be 
Created,  Retrieved,  Updated,  and/or  Deleted. 

The  Action  Diagrammer  is  available  in  the  IEW  Analysis  Workstation. 

When  an  AD  is  complete,  it  can  be  used  by  the  team  members  to  ensure 
that  a  complete  and  comprehensive  understanding  of  each  sequential 
process  has  been  recorded,  including  significant  processing  decision 
logic  based  on  classification  attribute  values.  The  AD  serves  as  the 
basic  outline  for  Module  Action  Diagrams,  which  represent  the  most 
detailed  program  logic  and  will  eventually  be  produced  in  the  IEW 
Design  Workstation. 
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3.2.2  COMPONENTS/TERMS 

3. 2. 2.1  Sequential  Processes 

A  Sequential  Process  is  a  process  whose  steps  or  subprocesses  are 
executed  one  at  a  time  in  a  prescribed  order.  It  has  identifiable 
inputs  and  outputs  expressed  as  information  views  of  the  data 
architecture  and  as  explicit  references  to  individual  Entities.  Each 
step  of  a  Sequential  Process  represents  either  an  individual  action,  a 
group  (block)  of  actions,  or  another  Sequential  Process.  Sequential 
Processes  may  be  performed  by  more  than  one  organizational  unit  in  a 
physical  system. 

3. 2. 2. 2  Action 

An  action  is  the  most  fundamental  unit  of  a  Sequential  Process  and  of 
an  AD.  An  action  consists  of  a  textual  description  of  an  elementary 
step  to  be  taken  (e.g.  'COMPARE  NUMBER  DELIVERED  WITH  NUMBER 
ORDERED/SPECIFIED  ON  CONTRACT').  However,  the  identification  of 
'Create,  'R'ead,  'U'pdate,  and  'D'elete  actions  (CRUD)  is  handled  in  a 
special  manner,  which  is  described  in  3. 1.2. 3  below. 

3.2.2. 3  Data  Access  or  Data  Store  Access 

Action  diagrams  represent  data  accesses  by  specifying  the  access  type 
followed  by  the  name  of  the  accessed  entity  type  in  a  rectangle.  There 
are  four  possible  access  types:  Create,  Read,  Update,  and  Delete.  The 
identification  of  Create,  Read,  Update,  and  Delete  actions  is  handled 
in  a  special  manner,  and  is  accomplished  by  utilizing  the  embedded 
'ADD'  pull  down  menu  (DATA  STORE  OPERATION).  Each  CRUD  Action  must  be 
coupled  with  a  reference  to  an  entity  from  the  Entity  Relationship 
Diagram  (ERD),  to  the  right  of  which  will  be  an  area  where  text  may  be 
manually  entered  to  describe  the  data  to  be  Created,  Retrieved, 

Updated,  and/or  Deleted. 

3. 2. 2. 3  Exit 

The  Exit  component  always  terminates  the  execution  of  a  block  of 
actions. 

3. 2. 2. 4  Repitition  Block 

Repetition  blocks  control  the  iteration  of  actions,  that  is,  how  often 
they  are  to  be  repeated.  There  are  three  kinds  of  repetition  blocks: 
the  Do  Until  block,  the  Do  While  block,  and  the  For  Each  block. 

3.2.2. 5  Selection  Block 

Selection  blocks  define  the  conditions  under  which  their  stated  actions 
are  to  be  executed.  There  are  three  types  of  selection  blocks:  the  If 
block,  the  If  Else  block,  and  the  Multiway  block. 
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3.2.3  INPUT  PRODUCTS 

3.2. 3.1  Entity/Relationship  Diagram  with  Classification  Entities 
(Figure  3. 2. 7-1) 

See  previous  definitions. 

3. 2. 3. 2  Process  Dependency  Diagram  (Figure  3. 2. 7-2) 

See  previous  definitions. 

3. 2. 3. 3  Detailed  Process  Description  (Figure  3. 2. 7-3) 

See  previous  definitions. 

3. 2. 3. 4  Process  Decomposition  Diagram  (Figure  3.2. 7-4) 

See  previous  definitions. 

3. 2. 3. 5  Logical  Information  Architecture  ( L I A )  CRUD  Associa . -c  \i  Matrix 
(Figure  3. 2. 7-5) 

See  previous  definitions. 
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3.2.4  GENERAL  PROCEDURES 


3.2.4. 1  Review  LIA  CRUD  Association  Matrix 

Review  the  functions  and  processes  in  the  LIA  CRUD  Association  Matrix. 
Identify  all  of  the  lowest-level,  in  scope-processes  which  'Create, 
'R'etrieve,  'U'pdate,  and/or  'D'elete  data. 

3. 2. 4. 2  Review  Process  Detail  Reports 

Review  the  detailed  descriptions  of  each  process  identified  previously 
in  the  LIA  CRUD  Association  Matrix.  Identify  those  processes  whose 
'COMMENTS'  Sections  mark  them  as  'SEQUENTIAL  PROCESSES'.  If  not  already 
done,  change  the  name  of  the  process  such  that  the  blank  space  between 
the  character  code  at  the  beginning  of  the  name  and  the  first  character 
of  the  descriptive  process  title  is  replace  with  a  minus  sign  ('-'). 

3. 2. 4. 3  Review  Process  Decomposition  Diagrams 

Locate  those  processes  identified  as  Sequential  Processes  on  the 
overall  Process  Decomposition  Diagram,  and  identify  the  parent  process. 

3. 2. 4. 4  Review  Process  Dependency  Diagrams 

For  each  process  identified  as  a  Sequential  Process  previously,  display 
the  Process  Dependency  Diagram  belonging  to  the  parent  process. 

3. 2. 4. 5  Develop  Action  Diagrams 

For  each  process  identified  as  a  Sequential  Process,  open  up  a  blank 
AD.  Input  the  contents  of  the  AD  based  upon  the  Data  Flows  identified 
in  the  Process  Dependency  Diagrams,  the  Action(s)  specified  in  the  LIA 
CRUD  Association  Matrix,  and  the  logic  described  in  the  Process  Detail 
Report  for  the  given  process.  When  the  AD  has  been  completed,  alter 
the  name  such  that  the  minus  sign  is  replaced  by  a  plus  ('+')  sign. 
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3.2.5  OUTPUT  PRODUCTS 


3.2. 5.1  Action  Diagrams 

Completed  Action  Diagrams  (AOs)  (see  Figure  3.2. 7-6)  represent  the  only 
output  products  from  this  effort.  It  should  be  understood  that  ADs  are 
documentative  representations  of  the  logic  and  syntax  of  sequential 
processes,  not  active,  embedded  models.  As  such,  ADs  are  themselves 
individual  constructs,  rather  than  collections  of  individual  constructs 
each  of  which  may  be  automatically  related  and  described  by  the  tools. 
To  understand  this  further,  think  of  the  Action  Diagrams  as  little  more 
than  sections  of  textual  descriptions  produced  in  a  word  processor. 
However,  the  tools  provide  a  powerful  and  efficient,  special  purpose 
text  editor  in  the  form  of  the  Action  Diagrammer  Facility,  which  allows 
for  the  quick  and  efficient  construction  of  these  semi-graphic 
descriptions.  In  a  later  phase,  another  form  of  Action  Diagrams 
(Module  Action  Diagrams  (MADs))  will  be  developed  based  upon  the 
content  of  these  ADs,  and  the  MADs  will  be  active,  embedded  process, 
modeling  components. 
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3.2.6  RULES 


3.2.6. 1  Sequential  Process  Naming  Notations 

3. 2. 6. 1.1  Initial  Identification  of  Sequential  Processes 

Upon  identifying  a  process  as  sequential  in  nature,  immediately  replace 
the  blank  space  between  the  alpha  process  code  and  the  first  character 
of  the  descriptive  name  with  a  minus  sign. 

3. 2. 6. 1.2  Removal  of  Sequential  Process  Identification 

3. 2. 6. 1.2.1  Removal  of  Notation 

Upon  identifying  a  process  previously  thought  to  be  sequential  in 
nature  as  a  non-sequential  process,  ensure  that  one  blank  space 
replaces  the  minus  or  plus  ('+')  sign  following  the  alpha  process  code 
and  before  the  first  character  of  the  descriptive  name. 

3. 2. 6. 1.2. 2  Return  Process  to  Full  Process  Status 

Upon  identifying  a  process  previously  thought  to  be  sequential  in 
nature  as  a  non-sequential  process,  ensure  that  the  process  is  viewed 
by  the  tool  as  a  non-sequential  process  by  entering  the  process's  AD, 
and  deleting  everything  (including  the  input  and  output  data  flows). 

3.2.6. 1.3  Final  Identification  of  Sequential  Processes 

Upon  completion  of  the  AD  for  a  sequential  process,  replace  the 
aforementioned  minus  sign  in  the  process's  name  with  a  plus  sign. 

3. 2. 6. 2  Data  Access  Conventions 

3. 2. 6. 2.1  Entity  Reads 

3. 2. 6. 2. 1.1  Data  Description 

When  performing  a  READ  Action  on  an  entity,  always  place  a  description 
of  the  data  to  be  read  to  the  right  of  the  entity  icon. 

3. 2. 6. 2. 1.2  Multiple  Reads 

When  more  than  one  type  of  information  is  to  be  read  from  the  same 
entity,  break  up  the  reading  process  into  more  than  one  READ  Action 
with  each  individual  type  of  information  description  to  the  right  of 
the  entity  icon  for  each  READ  Action. 

3. 2. 6. 3  Level  of  Detail 

Action  Diagrams  should  not  be  cryptic.  Feel  free  to  enter  as  much 
descriptive  text  as  is  necessary  to  completely  communicate  the  intent 
and  scope  of  each  individual  action  to  any  reader. 

3. 2. 6. 4  Embedded  Sequential  Processes 
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Individual  ADs  can,  in  place  of  a  block  of  actions,  reference  another 
sequential  process.  There  is  no  requirement  to  write  ADs  at  this  level 
that  do  that.  However,  if  there  comes  a  situation  where  this  is 
desirable,  please  adhere  to  the  following  rules: 

3. 2. 6. 4.1  Multiple  Access  to  Individual  Embedded  Sequential  Processes 

More  than  one  Action  Diagram  may  reference  the  SAME  embedded  process 
only  if  the  entire  Pilot  Team  agrees  that  the  embedded  process's 
requirements,  both  processing  and  data,  are  precisely  the  same  from  all 
ADs  that  reference  it. 

3. 2. 6. 4. 2  Dummy  Block  Notation 

Do  not  use  the  Embedded  Process  feature  to  mark  a  place  in  an  Action 
Diagram  where  a  block  of  actions  will  eventually  exist  but  for  whatever 
reason  cannot  be  identified  now.  Rather,  create  a  TITLE  BLOCK  bracket 
whose  title  is  DUMMY  BLOCK  <name>,  and  place  a  brief  description  of  the 
purpose  of  the  omitted  actions  within  the  TITLE  BLOCK  Bracket. 

3. 2. 6. 4. 3  Use  of  Keywords 

Certain  words  with  specific  meanings  and  implications  are  used  to 
describe  actions  embedded  within  the  Contractor  Profile  Action  Diagrams 
(ADs).  These  words  exist  only  in  that  portion  of  each  AD  entered  by 
the  AD's  author,  and  must  not  be  confused  with  the  IEW  generated, 
lower-case  reserved  words  such  as  'for  each',  'if',  'else',  and  so 
forth. 

The  attempt  must  be  made  to  utilize  these  keywords  in  a  consistant 
manner  throughout  the  Action  Diagramming  effort.  Still,  it  must  be 
understood  that  the  ADs  are  textual  in  nature,  and  although  a  certain 
level  of  rigor  and  structure  must  be  applied  during  their  creation, 
they  do  not  approach  the  level  of  structure  required  of  a  Program 
Definition  Language,  for  example.  As  such,  the  full,  proper,  and 
correct  understanding  of  any  particular  ion  must  come  not  only  from 
the  description  of  the  action  itself,  but  from  an  understanding  of  the 
action  within  its  surrounding  context. 

The  referenced  keywords,  along  with  definitions,  are  as  follows: 

KEYWORD  DEFINITION 

IDENTIFY  This  indicates  an  action  in  which  a  piece  of  information  is 
located,  scrutinized,  and  made  immediately  available  for 
use.  Normally,  the  referenced  piece  of  information  will  be 
a  subset  of  some  larger  information  set,  such  as  a 
document,  that  had  been  read  or  received  previously  within 
the  AD.  A  particularly  valuable  use  of  this  keyword  is 
identifying  pieces  of  information,  prior  to  a  'READ' 
action,  that  are  necessary  in  order  to  properly  execute  the 
read.  In  other  words,  in  order  to  identify  the  query 
criteria  for  the  given  READ. 

EXAMPLE  IDENTIFY  OFFEROR 
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IDENTIFY  BUYING  ACTIVITY 
(followed  perhaps  by  a  READ  operation  on  ALL 
HISTORIC  CONTRACTS  THAT  THE  GIVEN  BUYING 
ACTIVITY  HAS  AWARDED  TO  THE  GIVEN  OFFEROR) 

NOTE  This  keyword  implies  all  that  the  IDENTIFY  keyword  implies. 

Additionally,  the  act  of  'jotting  down1  the  given  piece  of 
information  is  implied,  such  that  it  may  be  used  later  on 
within  the  AD.  Typically,  this  keyword  may  be  used  to 
create  a  temporary  list  of  amalgamated  pieces  of  associated 
data,  sometimes  from  different  sources. 

EXAMPLE  for  each  HISTORIC  CONTRACT  FOR  GIVEN  OFFEROR 
NOTE  CONTRACT  NUMBER 
NOTE  START  DATE 
NOTE  END  DATE 
NOTE  BUYING  ACTIVITY 
for  each  DISCREPANCY  REPORT  FOR  GIVEN 
CONTRACT 

if  OFFEROR  WAS  RESPONSIBLE 

NOTE  DISCREPANCY  AND  DESCRIPTION 
NOTE  RESOLUTION 

(This  would  produce  a  single  list  of  all  of  the 
contracts  the  given  offeror  has  performed  on, 
along  with  certain  additional  information,  and 
for  each,  a  sub-list  identifying  all  of  the 
discrepancies  deemed  to  have  been  the  offeror's 
responsibility  and  each's  resolution) 

KEYWORD  DEFINITION 

DOCUMENT  This  keyword  implies  all  that  the  IDENTIFY  keyword  implies. 

Additionally,  the  act  of  permanently  storing  the  referenced 
information  such  that  it  may  be  READ  by  future  processes  is 
implied. 

EXAMPLE  CALCULATE  UNBURDENED  COST  OF  ITEM  = 

COST  PER  UNIT  X  NUMBER  OF  UNITS 
DOCUMENT  RESULT 

CALCULATE  The  CALCULATE  keyword  indicates  that  a  numerical  formula  is 
being  described.  A  CALCULATE  action  will  entail  input  or 
factorial  information,  and  a  result  datum.  See  the 
discussion  on  the  DOCUMENT  keyword  above  for  an  example. 

Often,  an  essential  action  within  a  process  derives  information  not 
through  the  application  of  a  numerical  or  logical  formula,  but  rather 
through  a  mental  process  as  applied  by  an  experienced  and  knowledgeable 
individual  or  group.  Sometimes  this  mental  process  is  structured  in 
accordance  with  pre-defined  guidelines  of  varying  detail,  and  other 
times  not.  In  any  case,  it  is  not  the  intent  of  the  AD  to  capture 
these  mental  processes  themselves,  but  rather  to: 

1.  Collect  all  of  the  information  required  in  order  to  properly 
apply  the  given  mental  process 


2.  Capture  the  result  of  the  mental  process 

3.  Describe  any  conditional  logic  based  upon  the  result  of  the 
mental  process 

Each  of  the  following  three  keywords  describes  the  application  of  a 
mental  process. 

KEYWORD  DEFINITION 

EVALUATE  This  keyword  indicates  that  a  judgement  of  some  type  must 
be  rendered  at  this  point,  normally  a  value  judgement. 

EXAMPLE  EVALUATE  THE  OFFEROR'S  QUALITY  PERFORMANCE 

HISTORY  AS  BEING  ADEQUATE  OR 
INADEQUATE 

DETERMINE  This  keyword  differs  from  EVALUATE  only  in  that  it  implies 
that  a  fairly  well-defined  set  of  guidelines  are  available 
to  base  the  determination  on,  and  that  the  given  mental 
process  is  more  structured  in  nature. 

EXAMPLE  DETERMINE  THE  MOST  EXPEDIENT  METHOD  OF 
DELIVERY 

FORMULATE  This  keyword  indicates  the  application  of  a  creative  mental 
process. 

EXAMPLE  FORMULATE  CORRECTIVE  ACTION  PLAN 

FORMULATE  QUALITY  ASSURANCE  LETTER  OF 
I NSTRUCT I ONS 

FORMULATE  DESCRIPTIVE  SUW1ARY  OF  OFFEROR'S 

HISTORIC  TRANSPORTATION  PERFORMANCE 
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3.2.7  EXAMPLES 

Figure  3. 2. 7-1  Entity/Relationship  Diagram  with  Classification 
Entities 

Figure  3.2. 7-2  Process  Dependency  Diagram 
Figure  3. 2. 7-3  Detailed  Process  Description 
Figure  3.2. 7-4  Process  Decomposition  Diagram 

Figure  3.2. 7-5  Logical  Information  Architecture  (LIA)  CRUD  Association 
Matrix 

Figure  3.2. 7-6  Action  Diagram 


) 
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-ROLE 


Process  Dependency  Diagrams 


Information  Engineering  Workbench  Report 
Object  Summary  Report 

J  ly  3,  1990  10:05:07  NEWUSER  V06  Page  1 

Process  AAAB  VALIDATE  PR  FOR  ADMIN  COMP 
PROPERTIES : 

DEFINITION: 

VALIDATE  PR  FOR  ADMINISTRATIVE  COMPLETENESS 


THIS  PROCESS  REVIEWS  THE  COMPLETE  PR  TO  ENSURE  THAT  ALL  THE  LANGUAGE  IS 
CORRECT  AND  COMPLETE,  FOR  EXAMPLE: 

A.  VALIDATE  DESCRIPTIVE  NSN  DATA 
E.  REVIEW  TECHNICAL  DATA  FILE  (ITEM  DATA) 

C.  REVIEW  PAST  BUY  HISTORY  (CONTRACTS).  CURRENT  AND  CLOSED  CONTRACTS 
FOR  THE  LAST  FIVE  YEARS  ( CONTRACT  HISTORY) 

D.  REVIEW  CONTRACTING  GUIDANCE  DATA 

E.  ENSURE  THAT  COMMITMENT  AUTHORITY  HAS  BEEN  ESTABLISHED 


Figure  3. 2. 7-3  Detailed  Process  Descriptions 
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PURCHASE 
R  E  Q 

PROCE  SS I  HO 


Figure  3.2.7-A  Process  Deconiposi  L  ion  Diagram 


offes 

|  LE2AL  ENTITY 
CCNTSACT 


AA  PURCHASE  REO  PROCESSING  (F) 

R 

R 

R  ! 

AAA  ASSURE  AGEOUACY  OF  PR 

R 

R 

R  I 

AAA A  Receive  Purchase  Request 

AAAS  Review  aid  Edit  PR 

R 

R 

r  ; 

AAA C  Assign  PR 

AAAO  Send  PR  to  3uyer 

AAAE  Buyer  Re1/.  PR  for  Aaequccy 

n-r  ■  .  —  =:•  .1..  ,-1  1  -  -  —  --a-  =a=g  —  .  -  —  -  -apr  i  =i 

P*3C3 js  i  nvalvei  Entity  7  y  p  « 


Figure  3. 2. 7-5  LIA  CRUD  Association  Matrix 
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*  CONDUCT  TRANSPORTATION  PRE-AWARD  SURVEY  (PAS) 

READ  REQUEST  FOR  TRANSPORTATION  PAS  (SF  1403) 
IDENTIFY  SOLICITATION 
IDENTIFY  OFFEROR 
READ  OFFER 

. — *  FOR  SOLICITATION  TRANSPORTATION  REQUIREMENTS 


Read 


L  N  I  TM 


Read 


SOU -E LMNT 


Read 


CLAUS 


Read 


ITEM 


IDENTIFY  SOLICITATION  LINE  ITEMS  (SLIN'S) 

Far  Each  SLIN 

IDENTIFY  ITEMS 

-  For  Each  ITEM 

— *  NOTE  THE  FOLLOWING: 

ITEM 

PLACE (S)  OF  ORIGIN 

INTERMEDIATE  PLACES  UITHIN  PROCESS 

DELIVERY  SCHEDULE 

PLACE  (S)  OF  DELIVERY 

EXPLICIT  TRANSPORTATION  REQUIREMENTS 

TRANSPORTATION  PRIORITIES,  AS  EVALUATED 

SHIPMENT  CHARACTERISTICS 

QUANTITY 

FREIGHT  ON  BOARD  (FOB)  TERMS 
FREIGHT  CLASSIFICATION  (NMFC  OR  UFC) 

READ  APPLICABLE  TRANSPORTATION  REGS /LAWS  ASSOCIATED  U/ITEM  TYPES 
vxvrc  ormiTocvrvrrc  *c  arueoiTcn  ov  tpoiirieic  orreii  rrmwc  tun  t  uic 
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*wik  rw  vutuvnu;  ui  n  »  l^vouu.  m  xwmi  xwnv  d«/ 

FORMULATE /NOTE  ADDITIONAL  REQUIREMENTS 


For  Each  ITEM  AS  NOTED 


Read 


P AS -RCMDN 


Read 


TRNSP  -C8LTY 


IDENTIFY  HISTORIC  PAS'S  FOR  GIVEN  OFFEROR 

-  For  Each  PAS  IDENTIFIED 

—  If  CURRENT  (TBD) 

NOTE  RECOMMENDATION  AND  JUSTIFICATION 
NOTE  TRANSPORTATION  FACILITIES 
—  If  FOR  SAME  /  SIMILAR  ITEM 

NOTE  UITH  SPECIAL  SIGNIFICANCE 


, — *  FOR  HISTORIC  CONTRACT  TRANSPORTATION  PERFORMANCE 


Read 


Read 


Read 


Read 
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Read 


DEFCN-INVSTh 


IDENTIFY  PAST  SHIPMENTS 

-  For  Each  PAST  SHIPHENT 

— *  NOTE  THE  FOLLOWING : 

ORIGIN 

DESTINATION 

WEIGHT 

ESTIMATED  COST 
CONTRACT  NUMBER 

TRANPORTATION  CONTROL  NUMBER  (FREIGHT  INFORMATION  SYSTEM) 
ACTUAL  DELIVERED  DATE  AT  DESTINATION 
ACTUAL  SHIPPING  CHARGES  PAID 
NAME  OF  CARRIER 

EVALUATE  CONTRACTOR'S  PERFORMANCE  FOR  GIVEN  SHIPMENT 
NOTE  RESULT 


IDENTIFY  SHIPMENT  DEFICIENCIES 

-  For  Each  PAST  DEFICIENCY  IDENTIFIED 

EVALUATE  IF  OFFEROR  UAS  RESPONSIBLE 
—  If  YES 

NOTE  DEFICIENCY  (DESCRIPTION) 
NOTE  DATE(S) 

NOTE  ITEM(S) 

NOTE  IMPACT  TO  GOVERNMENT 


SUMMARIZE/EVALUATE  LIST  OF  DEFICIENCIES 
NOTE  RESULT 

NOTE  TRANSPORTATION  FACILITY  INFORMATION  (CAPABILITY) 
EVALUATE  IF  ON-SITE  VISIT  REQUIRED 
, —  If  YES 


CONDUCT  ON-SITE  VISIT 

NOTE  CURRENT  FACILITIES' (CAPABILITIES) 
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tv aj.ua it  urrtxuK  S  urxutrcii anuinu  w  iiwotukiaixun  KtuuitttxitMa 
NOTE  RESULT 

DOCUMENT  CURRENT  FACILITIES/CAPABILITIES 


COMPARE  OFFEROR’S  CAPABILITIES  TO  REQUIREMENTS  AS  NOTED 
SUMMARIZE/EVALUATE/NOTE  RESULT  OF  COMPARISON 
COMPARE  OFFEROR'S  PERFORMANCE  HISTORY  TO  REQUIREMENTS  AS  NOTED 
SUMMARIZE/EVALUATE/NOTE  RESULT  OF  COMPARISON 

EVALUATE  OFFEROR'S  ABILITY  TO  MEET  TRANSPORTATION  REQUIREMENTS  AS  NOTED 
DOCUMENT  RESULT 


ABSCO+CONOUCT  TRANSPORTATION  PAS 


June  18.  1930  7:33:54 


Figure  3. 2.7-6  Action  Diagram 
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APPENDIX  A  -  DETAILED  IEW  PROCEDURES 

3.2  DEVELOP  ACTION  DIAGRAMS 

3.2.1  PURPOSE 

3.2.2  COMPONENTS/TERMS 

3.2.3  INPUT  PRODUCTS 

3.2.4  GENERAL  PROCEDURES 

3.2.4. 1  REVIEW  LIA  CRUD  ASSOCIATION  MATRIX 

3. 2. 4. 1.1  LOGON  TO  THE  PLANNING  WORKSTATION 

3.2.4. 1.2  PULL  DOWN  THE  ‘DISPLAY1  MENU  AND  SELECT  'ASSOCIATION 
MATRIX1 

3.2.4. 1.3  SELECT  'PROCESS'  FROM  THE  TOP  PORTION  OF  THE  DIALOGUE  BOX 

3. 2. 4. 1.4  SELECT  ‘ENTITY  TYPE'  FROM  THE  BOTTOM  PORTION  OF  THE 
DIALOGUE  BOX 

3. 2. 4. 1.5  PULL  DOWN  THE  'ASSOCIATION  MATRIX'  MENU  AND  SELECT  'SORT 
ROWS ' 

3. 2. 4. 1.6  PULL  DOWN  THE  'ASSOCIATION  MATRIX'  MENU  AND  SELECT  'SORT 
COLUMNS' 

3. 2. 4. 1.7  PULL  DOWN  THE  'ASSOCIATION  MATRIX'  MENU  AND  SELECT  'SHOW 
PROPERTIES' 

3. 2. 4. 1.8  SELECT  'ACTION'  FROM  THE  DIALOGUE  BOX  DISPLAYED 

3. 2.4. 2  REVIEW  PROCESS  DETAIL  REPORTS 

3. 2. 4. 2.1  PERFORM  STEPS  OUTLINED  IN  3. 1.4.1 

3. 2. 4. 2. 2  SELECT  EACH  PROCESS  IN  TURN  (ONE  AT  A  TIME)  BY  CLICKING 
THE  MOUSE  ON  IT. 

3. 2. 4. 2. 3  FOR  EACH  PROCESS  SELECTED,  PERFORM  THE  FOLLOWING  ACTIONS 

3. 2. 4. 2. 3.1  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  'DETAILS' 

3. 2. 4. 2. 3. 2  READ  THE  'DEFINITION'  AND  'COMMENTS'  BOXES 

3. 2. 4. 2. 3. 3  IF  THE  'COMMENTS'  BOX  INDICATES  THAT  THE  PROCESS  HAS  BEEN 
IDENTIFIED  AS  A  SEQUENTIAL  PROCESS,  PERFORM  THE  FOLLOWING 
ACTIONS 

3. 2. 4. 2. 3. 3.1  PLACE  THE  CURSOR  IN  THE  'TITLE'  BOX  DIRECTLY  TO  THE 
RIGHT  OF  THE  ALPHA  PROCESS  CODE  AND  LEFT  OF  THE 
FIRST  WORD  OF  THE  PROCESS'S  DESCRIPTIVE  TITLE 

3. 2. 4. 2. 3. 3.2  CHANGE  WHATEVER  IS  THERE  (PROBABLY  EITHER  A  SPACE  OR 
AN  ASTERISK)  TO  A  MINUS  SIGN 

3. 2. 4. 2. 3. 3. 3  PULL  DOWN  THE  'EDIT'  MENU  AND  SELECT  'SAVE' 

3. 2. 4. 2. 3. 3. 4  CLOSE  THE  'DETAILS'  DIALOGUE  BOX 

3. 2. 4. 2. 3. 3. 5  UNSELECT  THE  PREVIOUS  PROCESS  IN  THE  MATRIX  BY 
CLICKING  THE  MOUSE  ON  IT  ONCE,  AND  PROCEED  TO  THE 
NEXT  PROCESS 

3. 2. 4. 3  REVIEW  PROCESS  DECOMPOSITION  DIAGRAMS 

3. 2. 4. 3.1  LOGON  TO  ANALYSIS  WORKBENCH 
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3. 2. 4. 3. 2  PULL  DOWN  THE  'DISPLAY*  MENU  AND  SELECT  'DECOMPOSITION 
DIAGRAM’ 

3. 2. 4. 3. 3  CLICK  ON  THE  'PROCESS'  RADIO  BUTTON 

3. 2. 4. 3. 4  CLICK  ON  THE  'FIND'  RADIO  BUTTON 

3. 2. 4. 3. 5  IDENTIFY  AND  SELECT  THE  PROCESS  THAT  IS  THE  PARENT  TO  THE 
INDIVIDUAL  SEQUENTIAL  PROCESS  YOU  ARE  CURRENTLY  REVIEWING 

3.2.4. 3.6  CLICK  ON  THE  ‘PROCEED*  RADIO  BUTTON 

3. 2. 4. 4  REVIEW  PROCESS  DEPENDENCY  DIAGRAM 

3. 2. 4. 4.1  LOGON  TO  ANALYSIS  WORKBENCH 

3. 2. 4. 4. 2  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  'DATA  FLOW 
DIAGRAMMER' 

3. 2. 4. 4. 3  CLICK  ON  THE  'FIND'  RADIO  BUTTON 

3. 2. 4. 4. 4  IDENTIFY  AND  SELECT  THE  PROCESS  THAT  IS  THE  PARENT  TO  THE 
INDIVIDUAL  SEQUENTIAL  PROCESS  YOU  ARE  CURRENTLY  REVIEWING 

3. 2. 4. 4. 5  CLICK  ON  THE  'PROCEED'  RADIO  BUTTON 

3. 2. 4. 5  DEVELOP  ACTION  DIAGRAMS 

3. 2. 4. 5.1  LOGON  TO  ANALYSIS  WORKBENCH 

3. 2. 4. 5. 2  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  'OBJECT  LIST' 

3. 2. 4. 5. 3  CLICK  ON  THE  'DESELECT  ALL'  RADIO  BUTTON 

3. 2. 4. 5. 4  SELECT  'PROCESSES'  FROM  THE  DIALOGUE  BOX  AND  CLICK  ON  THE 
'PROCEED'  RADIO  BUTTON  (NOTE:  TO  MODIFY  AN  EXISTING  ACTION 
DIAGRAM,  SELECT  'SEQUENTIAL  PROCESSES'  RATHER  THAN 
'PROCESS') 

3. 2. 4. 5. 5  SELECT  THE  PROCESS  WHOSE  ACTION  DIAGRAM  YOU  WISH  TO  CREATE 

3. 2. 4. 5. 6  PULL  DOWN  THE  'DISPLAY*  MENU  AND  SELECT  'ACTION  DIAGRAM1 
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3.2  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 


3.2  DEVELOP  ACTION  DIAGRAMS 

There  are  no  PC  Dictionary  procedures  for  this  section  at  this  time. 
Decisions  need  to  be  made  as  to  what  should  be  stored  in  PC  DICTIONARY 
due  to  the  action  diagram  activity. 
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3.3  DEVELOP  ATTRIBUTE  DESCRIPTIONS 


Figure  3.3-1  Step  Overview 
Figure  3.3-2  Step  Products 
Figure  3.3-3  Step  Components 
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3.  I0ENT1FY  OTHER  ATTRIBUTE  INFORMATION 


INFORMATION  REQUIREMENTS  REPORT 


SCOPING 


FUNCTIONAL 

ARCHITECTURE 


MAPS 


DATA 

ARCHITECTURE 


3.3-2 


ENTITY  RELATIONSHIP  DIAGRAM 


3.3  DEVELOP  ATTRIBUTE  DESCRIPTIONS 
3.3.1  PURPOSE 

The  purpose  in  this  step  is  to  fully  describe  each  attribute.  This 
includes  revising  definitions,  identifying  legal  values,  noting  editing 
rules,  identifying  the  best  source  for  the  data,  noting  the  format, 
etc. 
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3.3.2  COMPONENTS/TERMS 
3.3.2. 1  Attribute 


3.3.3  INPUT  PRODUCTS 

3.3.3. 1  Attribute  Reports  (Reference  Figure  2. 1.7-3) 

These  reports  will  contain  the  brief  definitions  that  were  identified 
for  each  attribute  during  Global  Analysis. 
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3.3.4  GENERAL  PROCEDURES 


3. 3.4.1  Review  Attribute  Definitions 

Determine  if  the  definitions  are  correct  and/or  adequate.  The 
definitions  should  follow  the  rules  that  are  described  in  the  RULES 
section  of  this  procedure. 

3. 3. 4. 2  Determine  Attribute  Source 

If  an  attribute  is  currently  being  used  in  an  existing  system,  use  that 
information  as  a  start.  If  the  attribute  is  new  to  the  enterprise  or  a 
place  holder  for  future  use,  identify  it  as  such  within  the  dictionary. 

3. 3. 4. 3  Identify  Other  Attribute  Information 

This  includes  identifying  the  format  for  the  attribute  (e.g. 
Alphanumeric),  the  required  editing  rules,  and  the  legal  values.  All 
of  this  information  is  important  for  the  physical  implementation  of 
this  logical  design. 
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3.3.5  OUTPUT  PRODUCTS 

3. 3. 5.1  Attribute  Reports  (Figure  3. 3. 7-1) 

These  will  contain  the  complete  descriptions  for  all  attributes  that 
were  analyzed  during  this  step. 
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3.3.6  RULES 


3.3.6. 1  Complete  Sentences 

All  statements  within  a  definition  must  be  complete  sentences. 

3. 3. 6. 2  Grammatically  Correct 

All  statements  within  a  definition  must  be  grammatically  correct. 

3. 3. 6. 3  Circular  Statements 

Circular  statements  are  not  permitted  within  a  definition.  A  circular 
statement  is  one  in  which  the  component  being  defined  is  restated  and 
used  without  qualifications  or  other  explanation  as  the  definition  of 
the  component  being  defined,  e.g.,  an  information  requirement  is  a 
statement  of  a  firm's  requirements  for  information. 

3. 3. 6. 4  Objective  and  Quantitative  Statements 

Definitions  should  use  only  objective  and  quantitative  statements,  not 
qualitative  or  subjective  statements. 

3. 3. 6. 5  Ambiguity 

Definitions  must  be  free  of  ambiguity  so  that  they  cannot  be  subject  to 
interpretation  which  may  have  the  effect  of  changing  the  definition. 

3. 3. 6. 6  Stand  Alone 

A  definition  must  be  capable  of  standing  alone  without  the  need  for 
oral  interpretation  or  explanation  as  to  its  meaning  or  intent. 

3. 3. 6. 7  Organizational  Jargon 

Definitions  must  be  free  of  organizational  jargon,  idiom  or  other  terms 
which  may  be  known  only  to  insiders. 

3. 3. 6.8  Acronyms 

Acronyms  may  be  used  within  a  definition.  On  first  use,  the  full 
English  meaning  must  be  spelled  out  followed  by  the  acronym  itself. 

3. 3. 6. 9  Self  Contained 

Each  definition  must  be  self  contained  and  not  dependent  upon  the 
existence  or  content  of  another  definition. 

3.3.6.10  Personal  Pronouns 

Definitional  statements  should  not  begin  with  personal  pronouns,  e.g. 
It,  They,  His,  Our,  etc. 

3.3.6.11  Context 
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Definitions  must  place  the  component  within  a  specific  context  or  must 
state  each  occurrence  of  context  where  appropriate. 

3.3.6.12  Uniqueness 

If  the  definition  of  the  component  is  unique  within  DLA,  or  is  thought 
to  be  different,  it  must  be  stated  within  the  definition. 

3.3.6.13  Contents 

A  definition  may  contain  any  statements  necessary  to  convey  an 
understanding  of  the  component  being  defined,  its  context,  its 
activities,  its  reason  for  existence  or  its  reason  for  inclusion. 

3.3.6.14  Length 

A  definition  may  be  as  long  or  as  short  as  is  necessary. 


3.3.7  EXAMPLE 

Figure  3. 3. 7-1  Attribute  Report 
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Figure  3.3. 7-1  Attribute  Definitions 


358 


3.3  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 

3.3  DEVELOP  ATTRIBUTE  DESCRIPTIONS 

There  are  no  IEW  procedures  for  this  section. 
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3.3  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 


3.3  DEVELOP  ATTRIBUTE  DESCRIPTIONS 

Reference  APPENDIX  D,  GENERAL  PC  DICTIONARY  PROCEDURES,  for  more 
details  on  how  to  ADD,  EDIT,  DELETE,  COPY,  RENAME,  REPORT,  or  QUERY 
dictionary  members. 

3.3.1  PURPOSE 

The  purpose  in  these  PC  Dictionary  detailed  procedures  is  to  explain 
how  to  capture  and  report  the  information  that  is  gathered  during  the 
development  of  attribute  descr iptions. 

3.3.2  COMPONENTS/TERMS 

3.3.2. 1  Attribute 

3. 3. 2. 2  Context  Attribute 

Context  Attribute  is  the  dictionary  structure  member  type  that  is  used 
to  document  each  attribute  that  is  non-decomposable.  The  names  for 
context  attributes  begin  with  CT-  in  the  dictionary. 

3. 3. 2. 3  Concatenated  Attribute 

Concatenated  Attribute  is  the  dictionary  structure  member  type  that  is 
used  to  document  each  attribute  that  is  decomposable  into  context 
attributes.  The  names  for  concatenated  attributes  begins  with  CC-  in 
the  dictionary. 

3.3.3  INPUT  PRODUCTS 

3. 3. 3.1  Attribute  Reports 

Get  a  separate  report  for  each  set  of  attributes  (context  and/or 
concatenated)  that  are  assigned  to  one  entity  type.  This  should  be 
relatively  easy  to  do  since  the  attribute  names  begin  with  the  entity 
type  name,  following  the  member  type  prefix.  While  in  the  MEMBER 
DEFINITION  REPORT  function,  select  all  of  the  attributes  that  begin 
with  one  particular  entity  type  name.  Run  the  report.  Repeat  for  each 
entity  type. 

3.3.4  GENERAL  PROCEDURES 

3.3.4. 1  Review  Attribute  Definitions 

EDIT  any  attribute  whose  definition  needs  modifying  through  the  DATA 
ENTRY  function.  EDIT  the  'definition'  within  each  attribute  member. 
SAVE  the  'definition'. 

3. 3. 4. 2  Determine  Attribute  Source 

After  EDIT i ng  the  definition,  continue  EDIT i ng  the  attribute  member  by 
EDIT i ng  the  'source'.  Enter  the  name  of  the  existing  system  plus  any 
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other  text  that  helps  describe  the  source.  If  the  attribute  is 
new/future,  enter  text  that  explains  its  origin.  SAVE  the  ‘source*. 

3. 3. 4. 3  Identify  Other  Attribute  Information 

While  still  editing  the  attribute  member,  EDIT  the  ‘format1.  Enter  the 
proper  format  or  select  it  from  the  keyword  lookup  table.  Only  the 
values  in  the  lookup  table  are  allowed.  SAVE  the  'format*. 

EDIT  the  'editing-rules'  for  each  attribute.  Enter  any  text  that 
describes  how  the  data  being  described  is  edited  or  should  be  edited. 
SAVE  the  'editing-rules'. 

EDIT  the  'legal-values'  for  each  attribute.  Enter  the  code  values  that 
are  allowed  for  the  data  being  described  plus  the  meaning  for  each 
code.  SAVE  the  'legal-values'. 

SAVE  the  attribute  member. 

3.3.5  OUTPUT  PRODUCTS 

3. 3. 5.1  Attribute  Reports 

Repeat  the  steps  described  in  the  INPUT  PRODUCTS  section  of  this 
procedure. 
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4  NORMALIZATION 

4.1  PURPOSE 

Figure  4-1  Step  Overview 
Figure  4-2  Step  Products 
Figure  4-3  Step  Components 

4.2  COMPONENTS/TERMS 

4.2.1  Attribute 

4.2.2  Complex  Associative  Entity 

4.2.3  Composite  Foreign  Key 

4.2.4  Composite  Primary  Identifier 

4.2.5  Entity  (also  called  Entity  Type) 

4.2.6  Foreign  key 

4.2.7  Intelligent  Identifier 

4.2.8  Identifying  attribute 

4.2.9  Non-identifying  attribute 

4.2.10  Primary  identifier 

4.2.11  Relation 

4.2.12  Subentity 

4.2.13  Subtype 

4.3  INPUT  PRODUCTS 

4.3.1  Entity  names  and  definitions. 

4.3.2  Relationship  origins,  destinations  and  cardinalities. 

4.3.3  Attribute  definitions. 

4.3.4  Primary  identifiers  for  entities. 

4.4  GENERAL  PROCEDURES 

4.4.1  Entity  becomes  relation. 

4.4.2  Foreign  keys  for  relationship. 

4.4.3  "Intelligent"  identifiers. 

4.4.4  Record  initial  data. 

4.4.5  Record  changes. 

4.5  OUTPUT  PRODUCTS 

4.5.1  Relations  are  created. 

4.5.2  Attributes  are  assigned  membership  in  relations. 

4.5.3  Notation  of  attributes  as  identifying  and 
non-identifying. 

4.6  QUALITY  ASSURANCE  RULES 

4.6.1  Does  one  value  of  the  primary  identifier  determain  one 
value  of  the  attribute? 

4.6.2  For  a  relation  having  a  compound  primary  identifier:  Can 
one  value  of  the  attribute  be  determined  by  a  combination  of  some 
parts  of  the  primary  identifier?  (less  than  the  entire  identifier?) 
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4.6.3  Does  one  value  of  the  attribute  depend  on  the  value  of  any 
attribute  in  any  other  relation? 

4.7  EXAMPLE 

4  Appendix  A  -  Detailed  IEW  Procedures 
4  Appendix  B  -  Detailed  PC  Dictionary  Procedures 
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4  NORMALIZATION 


4.1  PURPOSE 

Data  normalization  is  a  technique  which  takes  individual  data  items  or 
facts  and  places  them  into  groups  which  describe  very  specifically  a 
real  or  abstract  object  which  exists  in  the  business  environment  being 
modeled.  In  normalization,  the  attributed  Entity  Relationship  model 
is  examined  in  detail  to  ensure  that  each  data  group  contains 
attributes  whose  values  are  absolutely  determined  by  their  respective 
primary  identifier.  In  general  the  entity  modeling  process  will  have 
produced  a  substantially  normalized  model. 

The  normalization  technique  produces  highly  cohesive  groups  of  data 
items,  and  thus  yields  a  model  of  the  business  objects,  concepts  and 
facts  which  is  very  flexible.  The  normalized  data  groups  eliminate 
the  redundant  representation  of  data  by  placing  each  fact  in  exactly 
one  data  group.  (The  only  exception  to  this  statement  concerns  the 
concept  of  foreign  keys.)  Another  benefit  that  results  from 
normalization  is  the  elimination  of  synchronization  anomalies  in  the 
updating  of  the  data,  since  each  fact  resides  in  only  one  place  in  the 
model.  This  technique  is  based  in  mathematics  and  applies  rigor  to  the 
data  model.  Still,  in  order  to  accomplish  normalization,  questions 
will  be  generated  whose  answers  lie  in  the  business  community. 

Although  the  theory  of  normalization  is  exact,  the  actual  products  of 
applying  the  technique  will  vary  according  to  the  perspective  and 
priorities  of  the  business  which  the  model  will  support. 

The  normalized  relational  model  which  is  the  product  of  this  procedure 
constitutes  the  third  of  four  levels  of  representation  of  the  data 
model.  The  levels  (conceptual,  substantive  logical,  detailed  logical 
and  physical)  each  represent  the  information  requirements  of  the 
enterprise  with  an  increasingly  finer  degree  of  resolution. 
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4.2  COMPONENTS/TERMS 

4.2.1  Attribute 

A  characteristic  or  quality  of  an  entity  that  is  of  interest  to  the 
business.  Attributes  are  members  of  entities  or  relations. 

4.2.2  Complex  Associative  Entity 

A  meaningful  "pairing"  of  instances  of  three  or  more  entities.  For 
example,  the  use  of  a  SKILL  by  an  EMPLOYEE  on  a  PROJECT.  These  groups 
are  scrutinized  in  taking  the  model  from  Fourth  to  Fifth  Normal  Form. 

4.2.3  Composite  Foreign  Key 

A  foreign  key  that  consists  of  more  than  one  attribute. 

4.2.4  Composite  Primary  Identifier 

A  primary  identifier  that  consists  of  more  than  one  attribute. 

4.2.5  Entity. 

Also  called  Entity  Type. 

4.2.6  Foreign  key 

A  set  of  attributes  in  a  relation  which  are  identical  to  the  primary 
identifier  of  another  relation.  The  foreign  key  may  or  may  not  be 
part  of  the  primary  identifier  in  the  relation  where  it  is  placed. 

4.2.7  Intelligent  Identifier 

A  primary  identifier  (usually  one  data  item  in  existing  systems)  which 
contains  meaning  that  characterizes  its  entity  in  one  or  more  ways. 
Investigation  often  reveals  multiple  components  in  this  "item".  These 
components  may  be  interpreted  in  multiple  ways  over  time  and  across 
the  enterprise,  significantly  compromising  the  potential  for  flexible 
data  processing  systems.  An  example  of  an  intelligent  identifier  is 
an  insurance  policy  number  where  the  first  three  characters  represent 
the  type  of  policy  (B0P123455  is  a  Business  Owner's  Policy,  etc.). 

4.2.8  Identifying  attribute 

An  attribute  which  is  all  or  part  of  a  primary  identifier. 

4.2.9  Non-identifying  attribute 

An  attribute  which  is  not  all  or  part  of  a  primary  identifier. 

4.2.10  Primary  identifier 

An  attribute  or  a  combination  of  attributes  whose  values  uniquely 
identify  an  instance  of  an  entity  or  relation.  An  entity  or  relation 
may  have  more  than  one  candidate  identifier. 
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4.2.11  Relation 

A  two-dimensional  representation  of  data  items.  A  relation  has  a 
name,  a  primary  identifier  and  a  set  of  non-identifying  attributes. 

The  attributes  can  be  thought  of  as  column  names,  and  actual  instances 
of  the  relation  may  be  thought  of  as  rows  in  the  relation. 

4.2.12  Subentity 

An  entity  which  has  a  compound  primary  identifier,  at  least  one  part 
of  which  is  not  a  foreign  key  or  foreign  key  component.  Also  called  a 
"child"  or  "dependent"  entity. 

4.2.13  Subtype 

An  entity  whose  occurrences  are  a  subset  of  those  of  another  entity 
(the  supertype).  The  occurrences  of  the  subtype  and  its  associated 
supertype  represent  exactly  the  same  instance  of  an  object  or  concept 
in  the  real  world,  but  the  subtype  has  additional  characteristics 
and/or  relationships  of  interest.  A  subtype  and  its  supertype  always 
have  identical  prime  identifiers. 
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4.3  INPUT  PRODUCTS 

The  only  input  to  the  data  normalization  process  is  the  attributed 
logical  entity  relationship  model.  The  information  specifically  used 
by  normalization  is: 

4.3.1  Entity  names  and  definitions. 

4.3.2  Relationship  origins,  destinations  and  cardinalities. 

4.3.3  Attribute  definitions. 

4.3.4  Primary  identifiers  for  entities. 
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4.4  GENERAL  PROCEDURES 


4.4.1  Each  entity  becomes  a  relation. 

Each  primary  identifier  of  an  entity  becomes  a  primary  identifier  of  a 
relation.  Each  attribute  of  an  entity  becomes  an  attribute  of  its 
corresponding  relation. 

4.4.2  Foreign  keys. 

Add  foreign  keys  for  each  relationship. 

4.4.3  "Intelligent"  identifiers. 

"Intelligent"  identifiers  become  non- identifying  attributes,  and 
single  attribute  primary  identifiers  are  created. 

4.4.4  Record  initial  data. 

Record  the  initial  relations  and  attributes  in  the  data  dictionary. 

4.4.5  Record  changes. 

The  following  steps  place  each  non-identifying  attribute  into  the 
relation  upon  whose  primary  key  the  attribute  completely  depends  for  a 
single  occurrence  of  its  value.  Record  any  changes  introduced  in 
these  steps  in  the  data  dictionary. 

For  each  relation, 

For  each  non-identifying  attribute  in  the  relation, 

If  a  given  value  for  the  primary  identifier  of  the  relation 
determines  only  one  value  for  the  attribute,  then 

The  attribute  is  placed  according  to  First  Normal 
Form.  Otherwise,  if  a  given  value  for  the  primary 
identifier  of  the  relation  permits  more  than  one  value 
for  the  attribute,  or  if  a  value  of  the  primary 
identifier  in  no  way  determines  the  value  of  the 
attribute,  then 

If  a  relation  exists  whose  primary  identifier  can 
determine  only  one  value  for  the  attribute,  then 

Move  the  attribute  into  that  relation. 

Otherwise, 

Create  a  new  relation  with  a  primary  identifier 
which  can  determine  only  one  value  for  the 
attribute. 

Move  the  attribute  into  that  relation. 
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If  a  given  value  for  the  entire  primary  identifier  of 
the  relation  determines  only  one  value  for  the 
attribute,  then 

The  attribute  is  placed  according  to  Second 
Normal  Form. 

Otherwise,  if  any  part  of  the  primary  identifier  of 
the  relation  is  not  required  to  determine  one  value  of 
the  attribute,  then 

If  a  relation  exists  whose  primary  identifier  can 
determine  only  one  value  for  the  attribute,  then 

Move  the  attribute  into  that  relation. 

Otherwise, 

Create  a  new  relation  with  a  primary 
identifier  consisting  only  of  those 
identifying  attributes  which  together 
determine  only  one  value  for  the  attribute 
being  placed. 

Move  the  attribute  into  that  relation. 

For  every  other  non-identifying  attribute  (say,  A2)  in  the 
relation, 

If  a  value  of  attribute  A2  has  no  effect  on  the  value 
of  the  attribute  being  placed,  then 

The  attribute  is  placed  according  to  Third  Normal 
Form  as  regards  attribute  A2. 

Otherwise,  if  a  given  value  of  attribute  A2  determines 
only  one  value  of  the  attribute  being  placed,  then 

Create  a  new  relation  with  attribute  A2  as  the 
primary  identifier. 

Move  into  the  new  relation  the  attribute  being 
placed. 

For  each  combination  of  attributes  (say,  PI)  in  the  primary 
identifier  of  a  relation  with  three  or  more  identifying 
attributes, 

For  every  other  combination  of  identifying  attributes  (say, 
P2), 


If  the  value  of  P2  has  no  effect  on  the  value  of  PI, 
then 


The  relation  adheres  to  Fourth  Normal  Form  as 
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regards  the  combinations  of  identifying  attributes 
PI  and  P 2. 

Otherwise,  if  a  value  of  combination  P2  has  no  effect 
on  the  value  of  PI,  then 

Create  a  new  relation  with  PI  as  the  primary 
identifier. 

Create  a  new  relation  with  P2  as  the  primary 
identifier. 

Mr"'e  the  non-identifying  attributes  from  the 
original  relation  into  one  of  the  new  relations 
according  to  the  rules  above. 
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4.5  OUTPUT  PRODUCTS 


Data  normalization  produces  the  following  objects  and  characteristics 

4.5.1  Relations  are  created. 

4.5.2  Attributes  are  assigned  membership  in  relations. 

4.5.3  Notation  of  attributes  as  identifying  and  non-identifying. 
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4.6  QUALITY  ASSURANCE  RULES 


The  correctness  of  the  normalized  relations  may  be  verified  by 
applying  the  following  tests  to  each  non-identifying  attribute  of  each 
relation: 

4.6.1  Does  one  value  of  the  primary  identifier  determine  one  value  of 
the  attribute? 

An  affirmative  response  is  required  to  confirm  normalization. 

4.6.2  For  a  relation  having  a  compound  primary  identifier:  Can  one 
value  of  the  attribute  be  determined  by  a  combination  of  some  parts  of 
the  primary  identifier?  (less  than  the  entire  identifier?) 

A  negative  response  is  required  to  confirm  normalization. 

4.6.3  Does  one  value  of  the  attribute  depend  on  the  value  of  any 
attribute  in  any  other  relation? 

A  negative  response  is  required  to  confirm  normalization. 
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4.7  EXAMPLE 


This  section  illustrates  by  example  the  normalization  process.  The 
example  begins  with  a  single  entity  called  EVALUATION  which  assesses 
an  employee's  performance  of  a  particular  skill  while  working  on  a 
particular  project.  In  a  real  modeling  circumstance,  most  of  the 
entities  corresponding  to  the  second  normal  form  relations  (2NF)  would 
probably  be  identified  prior  to  beginning  normalization. 

In  this  example,  the  boldface  words  are  the  names  of  the  relations; 
capitalized  words  are  attributes  in  primary  identifiers;  lowercase 
words  are  non-identifying  attributes;  and  "(F)"  following  an  attribute 
indicates  a  part  of  a  foreign  key. 

We  begin  with  an  unnormalized  relation  which  has  the  same  attributes 
as  the  EVALUATION  entity. 

Unnormalized 

EVALUATION 

EMPLOYEE 

PROJECT 

SKILL 

rating 

employee  name 
location  id 
project  start  date 
assignment  start  date 
phone  number 

To  arrive  at  the  First  Normal  Form  (INF)  relation(s),  we  ask  if  a 
given  value  of  the  primary  identifier  (EMPLOYEE  ID  +  PROJECT  ID  + 

SKILL  ID)  determines  only  one  value  for  each  non-identifying 
attribute.  That  is,  "Does  employee  #100  using  the  budgeting  skill  on 
project  ABC  have  exactly  one  rating?"  Then,  "Does  employee  #100  using 
the  budgeting  skill  on  project  ABC  have  exactly  one  employee  name?" 

And  so  the  analysis  continues  for  all  the  attributes.  In  our  example, 
there  is  only  one  INF  relation,  and  it  is  identical  to  the 
unnormalized  relation. 

INF 

EVALUATION 
EMPLOYEE 
PROJECT 
SKILL  ID 
rating 

employee  name 
project  start  date 
assignment  start  date 
location  id 
phone  number 

To  take  the  model  to  Second  Normal  Form  (2NF),  we  ask  if  any  non¬ 
identifying  attribute  in  the  relation  depends  on  only  part  of  the 
primary  identifier  for  its  value.  Several  of  the  attributes  in  this 
example  only  depend  on  part  of  the  primary  identifier  of  EVALUATION 
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for  their  value.  For  each  of  these  we  create  a  new  relation  with  an 
identifier  that  is  just  adequate  to  determine  the  attribute's  value. 
Three  more  2NF  relations  were  created  and  the  appropriate  attributes 
were  moved  into  those  relations. 

2NF 

EVALUATION 
EMPLOYEE  (F) 

PROJECT 
SKILL  ID 
rating 

PROJECT 

PROJECT 

project  start  date 

EMPLOYEE 
EMPLOYEE 
employee  name 

ASSIGNMENT 

EMPLOYEE 

PROJECT 

location  id 

phone  number 

assignment  start  date 

Third  Normal  Form  (3NF)  relations  are  produced  by  examining  non¬ 
identifying  attributes  for  any  dependence  they  may  have  on  attributes 
other  than  the  primary  identifier  attributes  of  their  relation.  In 
our  example,  the  business  representatives  tell  us  that  each  location 
has  one  phone  number;  phone  number  completely  depends  on  location  id 
from  the  point  of  view  of  our  example  business.  A  new  relation, 
LOCATION,  was  created  to  represent  this  fact.  At  this  point  all  the 
relations  conform  to  Third  Normal  Form  and  satisfy  the  Quality 
Assurance  Rules  1,2  and  3  in  section  4.6. 

3NF 

EVALUATION 
EMPLOYEE  (F) 

PROJECT  (F) 

SKILL  ID 
rating 

PROJECT 
PROJECT 
start  date 

EMPLOYEE 
EMPLOYEE 
employee  name 

ASSIGNMENT 
EMPLOYEE  (F) 

PROJECT  (F) 
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assignment  start  date 
location  id  (F) 

LOCATION 
LOCATION  ID 
phone  number 

To  exist  in  Fourth  Normal  Form,  any  part  of  a  primary  identifier  which 
can  have  values  completely  independent  of  the  other  part:  of  the 
primary  identifier  must  exist  as  a  primary  identifier  itself  in  the 
model.  In  a  sense,  this  process  asks  if  any  entities  have  been 
overlooked.  If  entity  analysis  has  been  thorough,  this  step  will 
typically  produce  no  changes.  In  our  example,  skill  id  is  independent 
of  the  other  parts  of  the  primary  identifier  of  the  EVALUATION 
relation,  and  so  a  new  relation,  SKILL,  is  created. 

4NF 

EVALUATION 
EMPLOYEE  (F) 

PROJECT  (F) 

SKILL  ID  (F) 
rating 

PROJECT 

PROJECT 

project  start  date 

EMPLOYEE 
EMPLOYEE 
employee  name 

ASSIGNMENT 
EMPLOYEE  (F) 

PROJECT  (F) 
assignment  start  date 
location  id  (F) 

LOCATION 
LOCATION  ID 
phone  number 

SKILL 
SKILL  ID 

skill  description 

Performing  the  analysis  to  produce  a  model  in  Fifth  Normal  Form  (5NF) 
can  often  reveal  subtleties  that  were  not  captured  during  entity 
modeling.  This  step  examines  relations  having  compound  primary 
identifiers  consisting  of  three  or  more  attributes.  We  ask  if  one 
instance  of  the  relation  actually  represents  more  than  one  independent 
fact  about  the  business.  In  our  example,  the  EVALUATION  relation  is 
the  only  place  in  the  model  where  a  particular  skill  is  paired  with  a 
particular  project,  and  this  exists  only  with  regard  to  a  particular 
employee's  performance  evaluation.  However,  upon  further  discussion 
with  the  business  representatives  we  discover  that  during  the 
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initiation  of  a  project,  a  profile  of  the  skills  required  by  the 
project  is  prepared  and  used  in  estimating  the  project  and  future 
projects.  Similarly,  our  business  maintains  a  record  of  which 
employees  possess  which  skills.  The  dependent  date  attributes  also 
become  apparent.  So  two  new  relations  are  created  to  represent  these 
two  independent  business  concepts,  and  their  attributes  are  added  to 
the  model . 

5NF 

EVALUATION 
EMPLOYEE  (F) 

PROJECT  (F) 

SKILL  ID  (F) 
rating 

PROJECT 

PROJECT 

project  start  date 

EMPLOYEE 
EMPLOYEE 
employee  name 

ASSIGNMENT 
EMPLOYEE  (F) 

PROJECT  (F) 
assignment  start  date 
location  id  (F) 

LOCATION 
LOCATION  ID 
phone  number 

SKILL 
SKILL  ID 

skill  description 

SKILL  REQUIREMENT 
SKILL  ID  (F) 

PROJECT  (F) 

Date  needed 

AVAILABLE  SKILL 
SKILL  ID  (F) 

EMPLOYEE  (F) 

Date  Available 
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4  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 
4  NORMALIZATION 

4.1  PURPOSE  (IEW) 

The  purpose  of  these  procedures  is  to  produce  a  relational  database 
design  from  an  attributed  entity  model.  Normalized  relations  are  the 
result  of  executing  these  procedures. 

These  procedures  employee  the  IEW  Relational  Translator  to  perform  the 
normalization  process. 

4.2  COMPONENTS/TERMS 
N/A 

4.3  INPUT  PRODUCTS  (IEW) 

Logon  to  the  IEW  Analysis  Workstation. 

Pull  down  the  "Display”  menu  and  select  "Encyclopedia  List". 

Select  the  encyclopedia  to  be  opened. 

Pull  down  the  "Edit"  menu  and  select  "Open". 

Close  the  window. 

Pull  down  the  "Display"  menu  and  select  "Entity  Diagram". 

Select  "Subject  Area"  and  "Find". 

Select  the  subject  area  to  be  used  for  normalization  and  select 
"Proceed" . 

Verify  that  this  is  the  subject  area  from  which  the  relational 
database  is  to  be  produced. 

4.4  PROCEDURES  (IEW) 

These  procedures  begin  with  the  desired  subject  area  entity  diagram 
window  open  and  active. 

4.4.1  -  4.4.4  IEW  procedures  are  not  applicable. 

4.4.5 

Pull  down  the  "Display"  menu  and  select  "Relational  Database  Design". 
Enter  the  name  of  the  database  to  be  created  and  select  "Creace". 
Select  "Foreign  keys"  and  "Only  where  necessary",  then  "Proceed". 
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When  more  than  one  possibility  exists  for  a  unique  identifier  of  a 
relation,  IEW  will  present  a  window  listing  the  choices. 

Select  the  "IDNTF"  attribute  if  present.  Otherwise,  select  the  "NBR" 
attribute.  Then  select  "Proceed". 

If  neither  "IDNTF"  nor  "NBR"  exist,  select  the  "CD"  attribute. 

The  Relational  Translator  will  generate  the  relations  for  the  selected 
subject  area. 

Return  to  the  manual  procedures  (Step  4. 4. 5. 1.2)  and  record  any 
changes  to  the  relations  by  editing  the  relation. 

4.5  OUTPUT  PRODUCTS  (IEW) 

The  steps  below  view  the  relations  produced  by  the  Relational 
Translator. 

Logon  to  the  IEW  Design  Workstation. 

Pull  down  the  "Display"  menu  and  select  "Encyclopedia  List". 

Select  the  encyclopedia  to  be  opened. 

Pull  down  the  "Edit"  menu  and  select  "Open". 

Close  the  window. 

Pull  down  the  "Display"  menu  and  select  "Database  Structure”. 

Select  "Relation"  and  "Find". 

Select  the  relation  to  be  viewed  and  select  "Proceed". 
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4  APPENDIX  B  -  DETAILED  PC  DICTIONARY  PROCEDURES 
4  NORMALIZATION 

There  are  no  PC  Dictionary  procedures  for  this  section  at  this  time. 
Decisions  need  to  be  made  as  to  what  should  be  stored  in  PC  Dictionary 
due  to  the  normalization  activity.  At  this  time,  a  relation  member 
type  is  being  considered.  Each  relation  will  contain  at  a  minimum  the 
key  plus  its  functionally  dependent  attributes. 
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5  DEVELOP  USER  VIEWS 

5.1  PURPOSE 

Figure  5.1-1  Step  Overview 
Figure  5.1-2  Step  Products 
Figure  5.1-3  Step  Components 

5.2  COMPONENTS/TERMS 

5.2.1  SCREEN  LAYOUT 

5. 2. 1.1  Labels 

5. 2. 1.2  Data 

5. 2. 1.2.1  Output  Data 

5. 2. 1.2. 1.1  Standard  Output  Data 

5. 2. 1.2. 1.2  Contextual  Output  Data 

5. 2. 1.2. 2  Input  Data 

5. 2. 1.3  Query  Criteria 

5. 2. 1.4  Functions/Commands 

5.2.2  DATA  VIEWS 

5.2.3  PROCESS  MODULE  LINKAGES 

5.3  INPUT  PRODUCTS 

5.3.1  DATABASE 

5.3.2  ACTION  DIAGRAMS 

5.3.3  MODULE  ACTION  DIAGRAMS 

5.4  GENERAL  PROCEDURES 

5.4.1  IDENTIFY  AUTOMATION  TARGETS  IN  ACTION  DIAGRAMS 

5.4.2  REVIEW  INFORMATION  VIEWS  FROM  TARGETED  ACTIONS 

5.4.3  DESIGN  SCREEN  LAYOUTS 

5.4.4  MAP  SCREEN  DATA  TO  THE  DATABASE 

5.4.5  MAP  SCREEN  DATA  TO  MODULES 

5.5  OUTPUT  PRODUCTS 
5.5.1  Screen  Layouts 

5.6  RULES 
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5.6.1  Maintain  Static  Data  Model 

5.6.2  Process  Driven 
5.7  EXAMPLES 

5  Appendix  A  -  Detailed  IEW  Procedures 

5  Appendix  B  -  Detailed  PC  Dictionary  Procedures 
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SCOPING 


SCOPING 


FUNCTIONAL 

ARCHITECTURE 


FUNCTIONAL 

ARCHITECTURE 


MAPS 


MAPS 


DATA 

ARCHITECTURE 
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ENTITY  RELATIONSHIP  DIAGRAM 


5  DEVELOP  USER  VIEWS 


5.1  PURPOSE 

User  Views  (UVs)  constitute  an  essential  component  in  the  creation  of  a 
viable  system.  Each  UV  provides  user  access  to  one  or  more  system 
processes,  and  to  one  or  more  views  of  the  database.  To  the  user,  the 
entire  collective  set  of  UVs  is  the  system,  as  access  to  all  system 
functionality  and  data  are  provided  to  the  user  through  the  User 
Views. 

A  User  View  is  at  once  both  a  discrete  object  and  a  junction  of  other, 
modeled  objects.  By  itself,  a  UV  may  be  evaluated  as  to  its  form, 
content  and  usefulness.  A  UV  provides  specific  information  designed 
to  address  one  or  more  explicitly  defined  information  needs.  As  a 
junction,  a  UV  may  be  evaluated  as  part  of  one  or  more  chains  of 
sequential  user  processes,  or  as  the  point  at  which  the  data,  process, 
and  functional  architectures  meet  to  address  one  or  more  system 
requirements. 
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5.2  COMPONENTS/TERMS 

5.2.1  SCREEN  LAYOUT 


A  screen  is  a  collection  of  graphic  and  textual  objects  which  together 
form  a  picture  that  may  be  displayed  on  a  terminal  or  printed.  Each 
of  the  objects  on  a  screen  constitutes  one  or  more  of  the  following 
types  of  objects 

5. 2. 1.1  Labels 

Any  portion  of  the  screen  which  is  fixed  such  that  it  does  not  change 
based  upon  the  value(s)  of  data  may  be  considered  a  label.  Column  and 
row  headers  (e.g.  such  as  a  month  at  the  top  of  a  column)  and 
individual  data  descriptors  (e.g.  "DATE:")  are  classic  examples  of 
labels.  However,  fixed  graphic  objects,  such  as  the  axis  of  a  graph, 
are  also  considered  labels. 

5. 2. 1.2  Data 

Any  portion  of  the  screen  which  changes  can  be  considered  data. 

5. 2. 1.2.1  Output  Data 

Output  data  is  that  portion  of  the  screen  whose  appearance  is  based 
upon  some  set  of  known  criteria,  and  is  produced  as  the  result  of 
decisions  and  actions  by  the  linked  process  module(s). 

5. 2. 1.2. 1.1  Standard  Output  Data 

Standard  output  data  is  that  output  data  which  is  consistent  within 
some  context.  For  example,  if  every  screen  shows  the  current  date, 
then  that  date  object  on  the  screen  can  be  considered  as  standard 
output  data  for  the  set  of  screens.  If  every  screen  showing  employee 
history  of  some  kind  displays  the  individual  employee's  id  in  the 
upper  right  hand  corner,  then  that  employee  id  object  can  be 
considered  as  standard  output  data  for  the  set  of  employee  screens. 
Thus,  it  can  be  seen  that  there  exist  levels  of  standardization  for 
standard  output  data  that  are  dependent  upon  the  size  and  scope  of  the 
set  within  which  that  object  is  standard. 

5. 2. 1.2. 1.2  Contextual  Output  Data 

Contextual  output  data  differs  from  standard  output  data  only  in  that 
its  appearance  is  standard  only  for  a  singular,  well-defined  context 
( i . e . ,  a  set  of  one) . 

5. 2. 1.2. 2  Input  Data 

Input  data  differs  from  output  data  in  that  it  is  produced  as  the 
result  of  decisions  and  actions  performed  by  the  user,  as  opposed  to 
the  linked  process  modules.  Like  all  screen  objects,  input  data  can 
take  a  textual,  graphics,  or  logical  form. 

5. 2. 1.3  Query  Criteria 
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Query  criteria  is  a  screen  object  which  constitutes  a  special  form  of 
data  (either  input  or  output),  and  represents  the  informational  basis 
used  to  retrieve  information  from  the  database.  For  example,  A  screen 
that  displays  a  contractor's  address  and  phone  number  may  provide  a 
blank  object  in  which  the  user  can  enter  the  cage  code  of  a  particular 
contractor.  That  cage  code  is  then  used  in  order  to  retrieve  the 
desired  information  for  the  given  contractor. 

5. 2. 1.4  Functions/Commands 

Functions  and  commands  are  special  forms  of  input  data  which  affect 
the  path  of  process  module  logic  and/or  the  display  of  information  on 
the  screen.  Functions  and  commands  may  be  local,  in  that  they  affect 
the  way  output  data  is  displayed  in  the  current  User  View,  for 
example,  or  global,  an  example  of  which  would  be  a  command  to  exit  one 
UV  and  execute  another. 
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5.2.2  DATA  VIEWS 


A  data  view  is  a  representation  of  a  portion  of  an  IEW  Database. 
Specifically,  that  portion  of  an  IEW  Database  which  contains  data 
structures  used  ('seen')  by  a  given  User  View.  In  other  words,  the 
database  information  used  by  a  given  UV  is  described  as  a  Data  View, 
which  maps  individual  data  structures  in  the  database  to  individual 
data  objects  on  the  screen. 

5.2.3  PROCESS  MODULE  LINKAGES 

A  Process  Module  Link  is  a  logical  association  between  a  screen  data 
object  and  a  particular  process  module.  The  given  process  module 
either  uses  or  produces  the  associated  datum. 
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5.3  INPUT  PRODUCTS 


5.3.1  DATABASE 

In  this  context,  database  refers  to  a  relational  schema 
(minimally  in  first  normal  form)  composed  of  data  structures,  each  of 
which  constitutes  a  repository  for  a  particular  type  of  datum. 

5.3.2  ACTION  DIAGRAMS 

Action  Diagrams  (ADs)  are  used  in  order  to  determine  which  individual 
actions  or  groups  of  process  actions  embody  in-scope  functional 
requirements.  By  analyzing  ADs,  one  can  identify  where  within  the 
process  architecture  a  User  View  may  be  placed  such  that  one  or  more 
functional  requirements  are  addressed.  The  portion  of  the  AD  thus 
identified  becomes  the  basis  for  a  Module  Action  Diagram,  which  is 
discussed  below. 

5.3.3  MODULE  ACTION  DIAGRAMS 

J  Module  Action  Diagrams  (MADs)  represent  detailed  program  logic  in 

I  graphic  format.  MADs  describe  the  points  in  the  system  which  directly 

I  interact  with  User  Views  through  the  individual  screen  data  objects. 
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5.4  GENERAL  PROCEDURES 


5.4.1  IDENTIFY  AUTOMATION  TARGETS  IN  ACTION  DIAGRAMS 

Action  Diagrams  are  reviewed  by  the  team  in  order  to  identify  actions 
or  groups  of  actions  which  represent  in-scope  functional  requirements. 
These  are  noted.  After  the  first  pass,  the  'targets'  are  summarized 
and  evaluated  as  a  whole  in  an  attempt  to: 

o  identify  duplicate  targets  (actions  or  groups  of  actions 
which  exist  in  more  than  one  context) 

o  continue  the  application  of  project  scoping  criteria 

o  evaluate  the  priority  of  individual  targets  respective  to 

all  targets  identified 

5.4.2  REVIEW  INFORMATION  VIEWS  FROM  TARGETED  ACTIONS 

The  information  view  for  each  AD  is  then  reviewed  to  ensure  that  the 
data  necessary  to  support  the  embedded  targets  is  present. 

5.4.3  DESIGN  SCREEN  LAYOUTS 

Functional  experts  then  review  each  identified  target  and  design  the 
screen  or  screens  that  address  its  information  requirements. 

5.4.4  MAP  SCREEN  DATA  TO  THE  DATABASE 

Each  screen  data  object  is  associated  with  a  specific  data  structure 
within  the  database,  if  appropriate.  There  are  instances  where  this 
would  not  be  appropriate.  For  example,  TODAY'S  DATE  may  have  no 
associated  structure  in  the  database. 

5.4.5  MAP  SCREEN  DATA  TO  MODULES 

Each  screen  data  object  (or  alternatively,  each  screen)  is  associated 
with  a  particular  MAD,  as  appropriate.  There  are  instances  where  this 
would  not  be  appropriate,  again,  as  in  the  case  of  TODAY'S  DATE. 
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5.5  OUTPUT  PRODUCTS 
5.5.1  Screen  Layouts 

The  output  of  the  User  View  development  will  be  in  the  form  of  IEW 
Screen  Layout  objects,  as  defined  in  Section  5.2.1.  See  Figure  5.7.1. 
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5.6  RULES 

5.6.1  Maintain  Static  Data  Model 

The  Development  of  User  Views  should  not  be  allowed  to  alter  or  modify 
the  current  version  of  the  data  model.  The  information  contained 
within  a  User  View  must  either  exist  in  the  current  data  model,  or  be 
derived  from  information  that  exists  in  the  current  data  model. 

5.6.2  Process  Driven 

The  User  Views  that  are  defined  must  be  derived  from  requirements 
identified  within  the  process  architecture  (from  the  Action  Diagrams). 
The  purpose  of  the  User  Views  is  to  support  the  sequential  processes 
that  have  been  described  in  great  detail. 
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5.7  EXAMPLE 


Figure  5.7.1  Screen  Layout 


5  APPENDIX  A  -  DETAILED  IEW  PROCEDURES 


5  DEVELOP  USER  VIEWS 

5.1  PURPOSE 

5.2  COMPONENTS/TERMS 

5.3  INPUT  PRODUCTS 

5.4  GENERAL  PROCEDURES 

5.4.1  IDENTIFY  AUTOMATION  TARGETS  IN  ACTION  DIAGRAMS 

5. 4. 1.1  LOGON  TO  ANALYSIS  WORKBENCH 

5. 4. 1.2  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  THE  'ACTION 
DIAGRAM'  OPTION 

5.4. 1.3  CLICK  ON  THE  'FIND'  RADIO  BUTTON 

5. 4. 1.4  SEARCH  FOR  THE  NEXT  ACTION  DIAGRAM  TO  BE  REVIEWED  AND 
SELECT  IT 

5. 4. 1.5  CLICK  ON  THE  'PROCEED'  RADIO  BUTTON 

5.4.2  REVIEW  INFORMATION  VIEWS  FROM  TARGETED  ACTIONS 

5.4.2. 1  LOGON  TO  ANALYSIS  WORKBENCH 

5. 4. 2. 2  PULL  DOWN  THE  'OBJECT  LIST'  OPTION 

5.4.2. 3  CLICK  ON  THE  'DESELECT  ALL'  RADIO  BUTTON 

5. 4. 2. 4  SELECT  'SEQUENTIAL  PROCESSES'  FROM  THE  LIST  PROVIDED 

5.4.2. 5  CLICK  ON  THE  'PROCEED'  RADIO  BUTTON 

5. 4. 2. 6  SELECT  THE  SEQUENTIAL  PROCESS  YOU  WISH  TO  REVIEW 

5. 4. 2. 7  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  THE  'ENTITY 
DIAGRAM'  OPTION 

5.4.3  DESIGN  SCREEN  LAYOUTS 

5. 4. 3.1  LOGON  TO  THE  ANALYSIS  WORKBENCH 

5. 4. 3. 2  PULL  DOWN  THE  'DISPLAY'  MENU  AND  SELECT  THE  'SCREEN 
LAYOUT'  OPTION 

5. 4. 3. 3  CLICK  ON  THE  'FIND'  RADIO  BUTTON 

5.4. 3.4  IF  YOU  SEE  THE  SCREEN  LAYOUT  YOU  WANT,  SELECT  IT  AND  CLICK 
ON  THE  'PROCEED'  RADIO  BUTTON. . .ELSE. . .ENTER  THE  NAME  OF 
THE  SCREEN  LAYOUT  YOU  WISH  TO  CREATE  AND  SELECT  THE 
'CREATE'  RADIO  BUTTON 

5.4.4  MAP  SCREEN  DATA  TO  THE  DATABASE 

5.4.5  MAP  SCREEN  DATA  TO  MODULES 


398 


5  APPENDIX  B  DETAILED  -  PC  DICTIONARY  PROCEDURES 
5  DEVELOP  USER  VIEWS 

There  are  no  PC  Dictionary  procedures  for  this  section  at  this  time. 
Decisions  need  to  be  made  as  to  what  should  be  stored  in  PC  DICTIONARY 
due  to  the  userview  activity. 
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APPENDIX  A  -  GLOSSARY  OF  TERMS 


Action  Diagram:  A  graphic  and  textual  depiction  of  the  detailed 
logic  and  sequential  actions  which  occur  when  a  process  is 
performed. 

Architecture:  A  structured  representation  of  the  component  parts 
of  a  complex  system  and  their  interrelationships. 

Attribute:  A  characteristic  of  an  entity  or  a  relationship. 

Attribute  Value:  A  quantitative  or  descriptive  characteristic  of 
an  entity  instance. 

Baseline  Architecture:  The  current  structure  of  component  parts 
of  an  automated  information  system  which  exists  to  accomplish  a 
specific  business  purpose. 

Business  Area:  A  logical  grouping  of  high  cohesive  functions 
within  a  business  or  organization. 

Business  Area  Analysis:  Detailed  analysis  of  a  selected  business 
area  to  define  logical  data  and  functional  models  in  preparation 
for  business  system  design. 

Business  Area  Functional  Model:  The  product  which  represents  a 
more  detailed  description  of  a  portion  of  the  Functional 
Architecture  at  the  Logical  level. 

Cardinality:  A  property  of  a  relationship  that  defines  whether  an 
occurrence  of  an  entity  can  relate  to  only  one  occurrence  of  the 
related  entity,  or  to  many  occurrences  of  the  related  entity. 

Classifying  Entity  Type:  An  entity  type  whose  single  purpose  is  to 
classify  or  categorize  Substantive  Entity  Types  or  Substantive 
Sub-entity  Types. 

Classifying  ERD:  An  entity  relationship  diagram  (ERD)  which 
contains  one  substantive  entity  type  only;  all  other  objects  are 
classifying  objects  relevant  to  the  classification  of  the  single 
substantive  entity  type  in  the  ERD. 

Classifying  Relationship:  A  relationship  between  a  classifying 
entity  type  or  classifying  sub-entity  type  and  any  other  entity 
type. 

Classifying  Sub-Entity  Type:  A  classifying  entity  type  which 
depends  on  the  existence  of  a  classifying  entity  type  or  on  another 
classifying  sub-entity  type. 
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Computer  Aided  Systems  Engineering  (CASE):  The  automation  of 
systems  engineering  using  automated  tools  which  aid  in  the 
development  of  consistent,  complete,  and  integrated  data  and 
process  models. 

Conceptual  Functional  Architecture:  The  highest  level  of  the 
Functional  Architecture.  Consists  of  a  structured  representative 
of  functions  for  the  entire  enterprise. 

Conceptual  Data  Architecture:  The  highest  level  of  the  Data 
Arch i tec Iture.  Consists  of  a  structured  representation  of  the 
entities  and  relationships  of  the  entire  enterprise. 

Corporate  Data  Dictionary  (CDD):  A  repository  of  data  about  an 
organization's  significant  information  and  information  processing 
resources,  and  a  directory  of  the  locations  and  relationships  of 
data  internal  and  external  to  the  directory. 

Constraint:  A  concept  that  represents  a  force  which  can  prevent  or 
limit  success. 

Critical  Success  Factor  (CSF):  A  concept  that  states  a  factor 
vital  to  the  success  of  an  enterprise,  a  thing  that  must  be  done 
well  if  the  enterprise  is  to  succeed. 

Data:  A  noncontextual  representation  of  facts,  concepts,  and 
instructions  in  a  defined  format  and  structure  which  permits 
processing  by  men  or  machines  to  derive  information. 

Representations  of  people,  places,  things,  concepts,  events  or 
activities  in  a  defined  format  and  structure  from  which  information 
may  be  derived. 

Data  Administration:  The  management  and  control  of  information  as 
a  corporate  asset. 

Data  Architecture:  The  structured  representation  of  an 
enterprise's  information  requirements  of  the  entire  enterprise, 
including  entities,  relationships  and  attributes. 

Data  Flows:  Information  about  one  or  more  entities  which  flows 
into  and  out  of  external  agents  to  and  from  processes.  Data  flows 
are  only  associated  with  external  agents  and  do  not  flow  between 
processes. 

DLA  Enterprise  Model:  The  representation  in  Entity  Relationship 
diagram  form  of  the  global  architecture  of  DLA  that  describes  the 
structure  of  the  enterprise  with  respect  to  its  business  direction, 
forces  that  influence  the  business,  and  its  operation. 

Enabler:  A  concept  that  represents  a  force  which  facilitates  or 
promotes  success. 

Enterprise  Model:  A  formal,  orderly,  automated  representation  of 
the  business  requirements  of  an  organization,  and  the  information 
which  is  required  to  support  those  business  requirements. 
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Entity:  A  person,  place,  thing,  event,  object,  or  concept  about 
which  an  enterprise  requires  information.  An  entity-type 
represents  all  of  the  occurrences  or  instances  of  a  given  type. 
Entity-types,  not  entities,  are  represented  in  a  data  architecture. 
Entity-types  may  be  "substantive"  or  classifying,"  and  may  be 
decomposable  into  subentity-types. 

Entity  Relationship  Diagram  (ERD):  A  graphic  model  which  portrays 
entities,  relationships,  and  relationship  properties  (optionality 
and  cardinality). 

Entity-Type  Description:  An  Entity-Type  Description  is  an  IEW 
report  which  displays  a  view  of  an  entity- type' s  characteristics 
relative  to  the  content  in  which  the  view  was  created.  The 
relevant  attributes  describing  the  entity-type,  as  well  as  the 
relevant  relationships  between  the  given  entity-type  and  other 
entity-types,  are  included  in  the  report. 

Exhaustiveness:  The  requirement  that  components  (entities, 
functions,  processes,  procedures)  at  the  same  level  completely 
decompose  the  parent  component. 

External  Agents:  Organizations  which  are  external  to  the 
enterprise. 

Facility:  A  place  which  exists  as  a  real  property  entity 
consisting  of  one  or  more  of  the  following:  a  building,  a 
structure,  a  utility  system,  pavement,  and  underlying  land. 

Function:  A  major,  high-level  activity  of  an  enterprise, 
comprising  a  broad  group  of  processes  that  together  completely 
support  one  aspect  of  furthering  a  mission  of  an  enterprise. 

Functional  Architecture:  The  structured  representation  of  an 
enterprise's  business  activities  (functions,  processes,  and 
procedures) . 

Goal:  A  concept  that  states  an  end  of  purpose  toward  which  an 
endeavor  is  directed. 

Global  Analysis:  A  phase  of  analysis  which  expands  vertically  the 
functional  and  data  architectures. 

Global  Architecture:  A  structured  representation  of  the  links 
between  an  organization’s  business  requirements  and  information 
requirements,  represented  by  an  enterprise  model. 

IE  Approach  Component:  An  element  of  an  IE  Approach  Product. 

IE  Approach  Product:  The  result  of  DLA's  Information  Engineering 
Approach  analyses.  Consists  of  components  and  may  be  portrayed  by 
one  or  many  subproducts. 
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IE  Approach  Subproduct:  A  specific  diagramming  or  documentation 
technique  for  portraying  an  IE  Approach  Product. 

Implementation  Platform:  Specific  hardware,  software, 
communications,  and  other  physical  items  used  in  producing  and 
operating  a  system. 

Information:  Data  (text,  figures,  number,  etc.)  in  the  context  of 
meaning. 

Information  Architecture:  A  structured  representation  of  the 
information  resources  of  the  organization  as  manifested  in  its 
data,  activities,  and  the  interaction  between  and  among  that  data 
and  those  actions.  The  Information  Architecture  consists  of  two 
subarchitectures:  the  Data  Architecture  and  the  Functional 
Architecture  -  and  the  mapping  between  the  two. 

Information  Engineering  (IE):  A  methodology  that  creates  a 
corporatewide  architectural  framework  for  information  systems 
containing  an  integrated  set  of  formal  techniques  in  which  business 
models,  data  models,  and  process  models  are  built  up  in  a 
comprehensive  knowledge  base  and  are  used  to  create  and  maintain 
the  information  systems. 

Information  Requirement  (IR):  The  functional  users'  way  of 
classifying  meaningful  data  which  they  need  to  perform  a  business 
function,  monitor  critical  success  factors,  or  achieve  a  measurable 
objective. 

Information  Requirements  List:  The  product  which  documents  the 
information  requirements  and  their  relationships  identified  in  the 
Enterprise  Model. 

Life  Cycle  Rule:  The  criteria  for  decomposing  groups  of  activities 
at  the  same  level  by  identifying  them  according  to  the  sequences  in 
which  a  function  or  process  must  be  executed. 

Logical  Data  Architecture:  A  detailed  structure  derived  from  the 
Conceptual  Data  Architecture.  Its  components  are  entities,  their 
relationships  to  each  other  and  the  properties  of  those 
relationships  and  their  attributes.  The  Logical  Data  Architecture 
delineates  the  real  or  user  perceived  roles,  aliases  and  subsets  of 
the  conceptual  entities. 

Logical  Functional  Architecture:  The  detailed  structuring  of  one 
business  area  from  the  Conceptual  Functional  Architecture.  Its 
components  are  processes  decomposed  to  the  level  of  sequential 
processes,  process  dependencies,  and  process  actions  relating 
processes  to  data  components. 

Mapping:  The  network  of  relationships  between  the  components  of 
the  data  architecture  and  business  system  architecture. 
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Mission:  A  concept  that  embodies  the  thing  to  be  done,  together 
with  the  purpose,  in  explanation  or  justification  for  the  existence 
of  the  organization. 

Mutual  Exclusivity:  The  requirement  that  components  (entities, 
attributes,  functions,  processes,  procedures,  relationships)  at  the 
same  level  do  not  overlap. 

Objective:  A  concept  that  represents  something  aimed  at  or  striven 
for  in  an  endeavor. 

Optional ity:  The  property  of  a  relationship  which  express  whether 
or  not  a  instance  of  a  relationship  must  occur  given  the  occurrence 
of  one  of  the  related  entities. 

Organization:  A  concept  that  represents  a  subdivision  of  an 
enterprise,  partitioned  along  human  resource  lines,  that  exists  to 
perform  one  or  more  process. 

Physical  Business  System  Architecture:  The  translation  of  a 
particular  Logical  Functional  Architecture  into  procedures  the 
system  will  implement. 

Physical  Data  Architecture:  The  translation  of  the  Logical  Data 
Architecture  into  the  actual  data  base  management  system  language 
that  will  be  implemented. 

Physical  Information  Architecture:  The  structure  of  actual 
business  system  and  data  base  designs  which  transform  logical 
designs  into  detailed  specifications. 

Physical  Level:  The  structure  of  data  or  procedures  as  they  exist 
in  physical  applications. 

Procedure:  A  group  of  activities  which  executes  a  process  carried 
out  by  a  specific  technique. 

Process:  A  low-level  action  or  group  of  actions  that  starts  or 
stops  and  is  repeatedly  executed  in  a  defined  sequence. 

Process  Action:  A  description  of  how  a  process  affects  entities, 
attributes,  and/or  relationships. 

Process  Dependency:  A  process  dependency  exists  when  one  process 
depends  on  other  processes  to  complete  a  task. 

Property:  A  characteristic  of  a  component  of  an  architecture. 

Relationship:  The  action  an  entity  takes  upon  or  receives  from 
another  entity.  Depicts  business  rules  of  an  enterprise. 

Strategy:  A  concept  that  embodies  a  scheme  or  plan  for  achieving 
some  purpose. 
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Subject  Area:  A  combination  of  entities,  relationships  and 
attributes  selected  to  satisfy  a  particular  user  or  functional 
view. 

Substantive  Entity  Type:  An  entity  type  which  is  meaningful  and 
relevant  to  the  enterprise  independent  to  the  existence  of  any 
other  entity  type. 

Substantive  ERD:  An  entity  relation  diagram  (ERD)  which  contains 
only  substantive  objects. 

Substantive  Relationship:  A  relationship  between  entities  of 
substantive  entity  types  of  between  sub-entity  types. 

Substantive  Sub-Entity  Type:  A  substantive  entity  type  which 
depends  on  the  existence  of  the  Entity  Type  to  which  it  is 
subordinate. 

System:  An  enterprise's  grouping  of  components  necessary  to 
achieve  an  aspect  of  its  mission;  includes  people,  organization, 
policy,  paper,  reports,  hardware,  software,  etc. 

Systems  Modernization  Methodology:  The  standard  methodology  which 
DLA  shall  use  in  the  application  of  the  principles  of  information 
engineering  (IE)  and  data  management  to  the  planning,  analysis, 
design,  acquisition,  and  deployment  of  its  information  resources. 

Target  Architecture:  A  structured  representation  of  the  desired 
architecture  to  accomplish  a  specific  business  purpose. 

Task:  A  concept  that  describes  a  specific  piece  or  amount  of  work, 
often  expected  to  be  finished  within  a  specific  time. 

Technical  Architecture:  The  structured  representation  of  hardware, 
systems  protocol  and  development  software,  end-user  devices,  and 
communication  links  which  support  application  systems. 

Unit  Analysis:  A  phase  of  analysis  where  the  lowest  level 
processes  and  data  components  are  further  defined  and  related 
together. 

User  Views:  A  system  design  component  which  represents  user  access 
to  system  processes  and  data;  serves  as  the  basis  for  development 
of  screen  layouts. 
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APPENDIX  B  -  LIST  OF  ACRONYMS 


AD 

Action  Diagram 

CDA 

Conceptual  Data  Architecture 

CFR 

Conceptual  Functional  Architecture 

CIA 

Conceptual  Information  Architecture 

CRUD 

Create  Read/Retrieve  Update  Delete 

DEC-D 

Decomposition  Diagram 

DEP-D 

Dependency  Diagram 

DLA 

Defense  Logistics  Agency 

EMC 

Enterprise  Model  Component 

E-R 

Entity  Relationship 

ERD 

Entity  Relationship  Diagram 

IEW 

Information  Engineering  Workbench 

IOM 

Interoffice  Memorandum 

JCS 

Joint  Chiefs  of  Staff 

LIA 

Logical  Information  Architecture 

MAD 

Module  Action  Diagram 

PCD 

PC  Dictionary 
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APPENDIX  C  -  GENERAL  IEW  PROCEDURES 


TABLE  OF  CONTENTS 

0.  LOGON  AND  PRINTING  PROCEDURES 

0.1  IEW  PROCEDURES 

0.1.1  IEW  LOGON  PROCEDURES 
0.1.2  IEW  PRINTING  PROCEDURES 
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0.  LOGON  AND  PRINTING  PROCEDURES 

0.1  IEW  PROCEDURES 

0.1.1  IEW  LOGON  PROCEDURES 


0.1. 1.1  TURN  ON  THE  COMPUTER 
0.1. 1.2  ENTER  "CIEW" 

0 '.  1 !  1 . 3  "INFORMATION  ENGINEERING  WORKBENCH"  WINDOW  IS  DISPLAYED 
0.1. 1.4  TO  RUN  THE  PLANNING  WORKSTATION: 

0.1. 1.4.1  ENTER  "1"  IN  THE  "ENTER  YOUR  SELECTION"  FIELD 

0.1. 1.4. 2  THE  "PLEASE  IDENTIFY  YOURSELF"  WINDOW  IS  DISPLAYED 

0.1. 1.4. 3  ENTER  "NEWUSER"  INTO  THE  "USER"  FIELD 

0.1. 1.4. 4  A  BLANK  WINDOW  IS  DISPLAYED  IN  THE  PLANNING  WORKSTATION 

0.1. 1.5  TO  RUN  THE  ANALYSIS  WORKSTATION: 

0.1. 1.5.1  ENTER  "2"  IN  THE  "ENTER  YOUR  SELECTION"  FIELD 

0.1. 1.5. 2  THE  "PLEASE  IDENTIFY  YOURSELF"  WINDOW  IS  DISPLAYED 

0.1. 1.5. 3  ENTER  "NEWUSER"  INTO  THE  "USER"  FIELD 

0.1. 1.5. 4  A  BLANK  WINDOW  IS  DISPLAYED  IN  THE  ANALYSIS  WORKSTATION 

0.1. 1.6  TO  RUN  THE  DESIGN  WORKSTATION: 

0.1. 1.6.1  ENTER  "3"  IN  THE  "ENTER  YOUR  SELECTION  FIELD 

0.1. 1.6. 2  THE  "PLEASE  IDENTIFY  YOURSELF"  WINDOW  IS  DISPLAYED 

0.1. 1.6. 3  ENTER  "NEWUSER"  INTO  THE  "USER"  FIELD 

0.1. 1.6. 4  A  BLANK  WINDOW  IS  DISPLAYED  IN  THE  DESIGN  WORKSTATION 
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0.1.2  IEW  PRINTING  PROCEDURES 


EXECUTING  THESE  PRINT  PROCEDURES  ASSUMES  THAT  THE  USER  IS  IN  ONE  OF 
THE  "DISPLAY"  WINDOWS  OF  THE  WORKSTATIONS,  SUCH  AS: 

PLANNING  WORKSTATION: 

-  ASSOCIATION  MATRIX 

-  DECOMPOSITION  DIAGRAM 

-  ENTITY  DIAGRAM 

0.1. 2.1  PULL  DOWN  THE  LEFT-MOST  WINDOW 
0.1. 2. 2  SELECT  "FILE  OUTPUT" 

0.1. 2. 3  "CREATE  A  PRINT  FILE"  WINDOW  IS  DISPLAYED 
0.1. 2. 4  PRESS  "PROCEED" 

0. 1.2.5  "NOTE"  WINDOW  IS  DISPLAYED 
0.1. 2. 6  PRESS  "PROCEED"  KEY 
0.1. 2. 7  PULL  DOWN  THE  LEFT-MOST  WINDOW 
0.1. 2. 8  SELECT  "QUIT" 

0.1. 2. 9  "NOTE"  WINDOW  IS  DISPLAYED 
0  1.2.10  PRESS  "PROCEED"  KEY 

o! 1.2. 11  "INFORMATION  ENGINEERING  WORKBENCH"  MAIN  MENU  IS  DISPLAYED 
0.1.2.12  ENTER  "4"  TO  "RUN  THE  OUTPUT  PROGRAM" 

0.1.2.13  "OUTPUT"  WINDOW  IS  DISPLAYED 
0.1.2.14  PRESS  "ADD  NAME"  KEY 

0.1.2.15  SELECT  " LMVER10"  DIRECTORY  WITHIN  THE  "*.GEM"  WINDOW 
0.1.2.16  THE  FILES  WITHIN  THE  DIRECTORY  ARE  DISPLAYED  WITHIN  THE 
"*.GEM"  WINDOW 

0.1.2.17  SCROLL  DOWN  THE  LISTING  AND  SELECT  THE  "KWDIAG.GEM"  FILE 
0.1.2.18  PRESS  "OK"  KEY 

0.1.2.19  SELECT  THE  "LASER  PRINTER"  ICON  (TOP  RIGHT  OF  SCREEN) 
0.1.2.20  PRESS  "START"  KEY 

o! 1 .2.21  AFTER  THE  "HOUR  GLASS"  ICON  DISAPPEARS,  PULL  DOWN  THE 
"FILE"  MENU 

0.1.2.22  SELECT  "QUIT" 

0.1.2.23  "INFORMATION  ENGINEERING  WORKBENCH"  WINDOW  IS  DISPLAYED 
0.1.2.24  FOLLOW  THE  "LOGON  PROCEDURES"  TO  RETURN  TO  THE  DESIRED 
WORKSTATION  (I.E.,  PLANNING,  ANALYSIS,  OR  DESIGN) 
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APPENDIX  D  -  GENERAL  PC  DICTIONARY  PROCEDURES 
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1. 


PURPOSE 


The  purpose  of  these  PC  DICTIONARY  detailed  procedures  is  to  explain 
the  basics  of  operating  PC  DICTIONARY. 

2.  COMPONENTS/TERMS 

2.1  MEMBER 

The  basic  component  of  the  data  dictionary.  Member  is  to  the  data 
dictionary  as  word  is  to  Webster's.  A  member  is  anything  you  wish  to 
document  in  a  data  dictionary.  It  is  also  known  as  a  dictionary 
entity.  Examples  of  members  for  the  entity  member  type  are  contract, 
line  item,  legal  entity,  and  government  agency. 

2.2  MEMBER  TYPE 

A  category  of  members.  Examples  of  member  types  are  function,  process, 
entity,  context  attribute,  and  concatenated  attribute.  Each  member 
type  can  have  many  members  associated  with  it.  A  member  may  have  only 
one  member  type. 

2.3  ATTRIBUTE 

A  descriptive  characteristic  or  property  of  a  member.  A  complete  set 
of  populated  attributes  provides  the  full  definition  of  a  member.  Also 
called  a  "clause".  Examples  of  attributes  for  the  context  attribute 
member  type  are  definition,  description,  alias,  legal  values  and 
editing  rules.  NOTE:  This  term  has  a  different  meaning  in  Procedures 
2.1.  It  is  used  here  in  Appendix  0  in  context  of  the  dictionary 
structure. 

3.  INPUT  PRODUCTS 

Does  not  apply  to  these  procedures. 

4.  GENERAL  PROCEDURES 

4.1  LOGON 

4.1.1  At  C:\  prompt,  change  directory  to  PCDICT. 

4.1.2  Enter  PCDICT  to  initiate  PC  Dictionary. 

4.1.3  Takes  you  to  main  menu. 

4.2  GENERAL  GUIDELINES 

4.2.1  Refer  to  template  at  bottom  of  screens. 

4.2.2  Use  FI  for  HELP;  definitions,  syntax,  and  examples  of  each 
attribute  are  in  the  HELP  within  DATA  ENTRY. 

4.2.3  Use  F2  whenever  appropriate  for  a  look  up  list;  saves  keystrokes 
and  possible  misspellings. 
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4.2.4  Use  ALT-F7  to  see  a  list  of  the  hot  keys:  ALT-F10  report 
destination  ALT-E  error  log  ALT-N  version  of  PC  Dictionary 

4.3  GENERIC  'HOW-TO-ENTER'  PROCEDURES 

Following  are  the  generic  procedures  for  how  to  Add,  Edit,  Delete, 
Copy,  or  Rename  a  dictionary  member. 

4.3.1  ADD  a  new  member 

4. 3. 1.1  Select  DATA  ENTRY  from  MAIN  MENU. 

4. 3. 1.2  Enter  appropriate  name,  following  Naming  Conventions  found  in 
the  Appendix  E. 

4. 3. 1.3  Enter  appropriate  member  type  or  select  from  look  up  list 
[F2] . 

4. 3. 1.4  Enter  necessary  attributes  (reference  Section  4.4  for  more 
details). 

4. 3. 1.5  Save  new  member  [F10]. 

4.3.2  EDIT  a  local  dictionary  member 

4. 3. 2.1  Select  DATA  ENTRY  from  MAIN  MENU. 

4. 3. 2. 2  Enter  appropriate  member  name  or  select  from  look  up  list 
[F2] . 

4. 3. 2. 3  Edit  desired  attributes  (reference  Section  4.4  for  more 
details). 

4. 3. 2. 4  Save  edited  member  [F 10] . 

4.3.3  DELETE  a  local  dictionary  member 

4.3.3. 1  Select  DATA  ENTRY  from  MAIN  MENU. 

4. 3. 3. 2  Enter  appropriate  member  name  or  select  from  look  up  list 
[F2] . 

4. 3. 3. 3  Delete  member  [F6] . 

4.3.4  COPY  a  local  dictionary  member 

4. 3.4.1  Select  DATA  ENTRY  from  MAIN  MENU. 

4. 3. 4. 2  Enter  member  name  to  copy  from  or  select  from  look  up  list 
[F2] . 

4. 3. 4. 3  Invoke  copy  command  [F7] . 

4. 3.4.4  Enter  new  name. 

412 


4.3.5  RENAME  a  local  dictionary  member 

4. 3. 5.1  Select  DATA  ENTRY  from  MAIN  MENU. 

4. 3. 5. 2  Enter  member  name  to  rename  or  select  from  look  up  list  [F2] . 

4. 3. 5. 3  Invoke  copy  command  [F7 ] . 

4. 3. 5. 4  Enter  new  name. 

4. 3. 5. 5  Invoke  delete  command  for  old  member  [F6] . 

4. 3. 5. 6  From  data  entry,  bring  up  look-up  list  again  {F2}  to  see  if 
old  name  still  exists,  but  is  NULL. 

4.3. 5. 7  If  it  is  NULL,  go  to  QUERY  menu. 

4. 3. 5.8  Select  WHAT  USES. 

4. 3. 5. 9  Select  DIRECTLY. 

4.3.5.10  Select  BY  MEMBER  NAME. 

4.3.5.11  Select  old  member  name. 

4.3.5.12  If  old  member  name  is  used  in  other  members  do  the  following: 

4.3.5.12.1  Edit  each  member  that  uses  the  old  member  name. 

4.3.5.12.2  Edit  the  relationship  that  contains  the  old  member  name. 

4.3.5.12.3  Delete  the  old  member  name. 

4.3.5.12.4  Add  the  new  member  name. 

4.3.5.12.5  Save  relationship. 

4.3.5.12.6  Save  member. 

4.4  GENERIC  'HOW-TO-ENTER'  ATTRIBUTES  BASED  ON  ATTRIBUTE  TYPE 

Adding,  Editing,  Deleting,  Copying,  and  Renaming  dictionary  members  are 
fairly  straight  forward  functions,  but  there  are  different  ways  to 
enter  attribute  information  based  on  the  attribute  type.  A  SHOW  UDS 
REPORT  aids  in  determining  how  to  enter  attributes  for  any  member  type. 
It  provides  the  following  information: 

MEMBER  TYPE:  Names  each  member  type  established  in  the  current 
dictionary.  ATTRIBUTE  NAME:  Specifies  each  attribute  that  can  be 
populated  for  each  member  type  ATTRIBUTE  TYPE:  Specifies  what  type  of 
information  can  be  entered  for  each  attribute  REQUIRED:  Specifies 
whether  the  attribute  is  required  to  be  populated.  PC  ONLY:  Specifies 
whether  the  attribute  should  go  to  the  mainframe  Corporate  Data 
Dictionary  VALIDATION:  Specifies  what  type  of  validation  has  been 
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established  for  each  attribute.  LENGTH:  Specifies  the  length  of  the 
attribute  field. 

The  following  procedures  explain  how  to  enter  attribute  information 
based  on  the  attribute  type.  A  SHOW  UDS  REPORT  should  be  referenced 
while  looking  at  the  screen,  until  you  learn  the  system. 

4.4.1  ATTRIBUTE  TYPE  -  ALIAS 

4. 4. 1.1  Press  F8. 

4. 4. 1.2  Key  in  specific  or  general  Alias. 

4. 4. 1.3  Save  Alias(es)  [F 10] - 

4.4.2  ATTRIBUTE  TYPE  -  CATALOG 

4.4.2. 1  Press  F8. 

4. 4. 2. 2  Add  Catalog(s)  or  select  from  look  up  list  [F2] 

4.4. 2. 3  Save  Catalog(s)  [F 10] . 

4.4.3  ATTRIBUTE  TYPE  -  KEYWORD 

4. 4. 3.1  Press  F2  for  lookup  list. 

4. 4. 3. 2  Use  arrow  key  to  highlight. 

4. 4. 3. 3  Press  ENTER  to  select  desired  keyword. 

4.4.4  ATTRIBUTE  TYPE  -  RELATION 

(To  Add  A  Relation) 

4.4.4. 1  Press  F8. 

4. 4. 4. 2  Add  sub-member  or  select  from  look  up  list  [F2 ] . 

4. 4. 4. 3  Save  sub-member  [F10]. 

4. 4. 4. 4  Repeat  add  and  save  for  each  sub-member. 

4.4.4. 5  Save  Relation(s)  [F10] . 

(To  Edit/Delete  Relation) 

4. 4. 4. 6  Press  F8. 

4.4.4. 7  Delete  member  {F6}. 

4. 4. 4. 8  Enter  sequence  #  of  member  to  delete. 

4. 4. 4. 9  Save  Relation(s)  {F10}. 

4.4.5  ATTRIBUTE  TYPE  -  RELATION  WITH  BOUND 
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4.4. 5.1  Press  F8. 

4.4. 5.2  Add  sub-member  or  select  from  look  up  list  [F2] . 

4.4. 5. 3  Bound  and  clause  are  optional. 

4. 4. 5. 4  Save  sub-member  [F10] . 

4.4. 5. 5  Repeat  add  and  save  for  each  sub-member. 

4.4. 5.6  Save  relation(s)  with  bound  [F10] . 

4.4.6  ATTRIBUTE  TYPE  -  RELATION  WITH  CLAUSE 

4.4.6. 1  Press  F8. 

4. 4. 6. 2  Add  sub-member  or  select  from  look  up  list  [F2] . 

4. 4. 6. 3  Clause  is  optional. 

4. 4. 6. 4  Save  sub-member  [F10] . 

4. 4. 6. 5  Repeat  add  and  save  for  each  sub-member. 

4. 4. 6. 6  Save  relation(s)  with  clause  [F10]. 

4.4.7  ATTRIBUTE  TYPE  -  STRING 

4. 4. 7.1  Key  in  directly.  4.4. 7.2  Field  will  scroll. 

4.4.8  ATTRIBUTE  TYPE  -  TEXT 

4.4.8. 1  Press  F8. 

4.4.8. 2  Word  wrap  feature. 

4.4.8. 3  May  use  extra  Clipper  commands:  CTRL-Y  delete  entire  line 
CTRL-N  insert  a  line  CTRL-W  save  input  CTRL-M  moves  the  text 
following  the  cursor  to  the  next  line  of  in  insert  mode. 

4. 4. 8. 4  Save  text  [F10]. 

4.5  REPORTS 

The  following  sections  explain  how  to  get  reports  from  your  local 
dictionary,  pertaining  to  the  dictionary  structure  plus  one  report 
containing  all  currently  populated  information. 

4.5.1  SHOW  UDS 

This  report  displays  the  structure  of  your  local  dictionary  including 
member  types,  attributes,  and  validation. 

4. 5. 1.1  Select  SHOW  UDS  REPORT  from  REPORT  MENU. 
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4.5. 1.2  Select  member  type(s)  [SPACE  BAR]. 

4. 5. 1.3  Check  report  destination  [ALT-F10]. 

4. 5. 1.4  Print  report  [F10-G0]. 

4.5.2  ATTRIBUTE  DEFINITION 

This  report  provides  an  alphabetical  listing  of  any  or  all  of  the 
attributes  which  can  be  populated  in  your  local  dictionary;  this 
report  prints  attributes  independent  of  the  member  type(s)  to  which 
they  are  associated. 

4. 5. 2.1  Select  ATTRIBUTE  DEFINITION  from  REPORT  MENU. 

4. 5. 2. 2  Select  attribute(s)  [SPACE  BAR]. 

4. 5. 2. 3  Check  report  destination  [ALT-F10]. 

4. 5. 2.4  Print  report  [F10-G0] . 

4.5.3  MEMBER  DEFINITION 

This  report  gives  all  of  the  information  currently  documented  in  your 
local  dictionary  about  any  member(s)  you  select. 

4.5.3. 1  Select  MEMBER  DEFINITION  from  REPORT  MENU. 

4. 5. 3.2  Select  member(s)  [SPACE  BAR]. 

4. 5. 3. 3  Check  report  destination  [ALT-F10]. 

4. 5. 3. 4  Print  report  [F10-G0]. 

4.5.4  CATALOGUE  LISTING 

This  report  consists  of  all  unique  catalogue  names  and  the  number  of 
occurrences  of  each  in  your  local  dictionary. 

4. 5.4.1  Check  report  destination  [ALT-F10]. 

4. 5. 4. 2  Select  CATALOGUE  LISTING  from  REPORT  MENU. 

4.5.5  SPECIFIC  ALIAS 

This  report  provides  a  list  of  all  valid  specific  aliases  which  can  be 
documented  in  your  local  dictionary. 

4.5. 5.1  Select  SPECIFIC  ALIAS  REPORT  from  REPORT  MENU. 

4. 5. 5. 2  Check  report  destination  [ALT-F10]. 

4. 5. 5. 3  Select  alphabetic  or  numeric. 

4.5.6  ALIAS  LISTING 
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This  report  generates  a  list  of  the  values  and  the  number  of 
occurrences  of  all  aliases  in  your  local  dictionary. 

4. 5. 6.1  Check  report  destination  [ALT-F10] . 

4. 5. 6. 2  Select  ALIAS  LISTING  from  REPORT  MENU. 

4.6  QUERIES 

The  following  instructions  tell  how  to  query  your  local  dictionary, 
basically  for  attribute  or  relationship  information  that  was  entered 
through  DATA  ENTRY. 

4.6.1  GLOSSARY 

Use  this  query  when  you  only  want  to  report  certain  attribute(s)  within 
certain  member  type(s). 

4. 6. 1.1  Select  GLOSSARY  from  QUERY  MENU. 

4. 6. 1.2  Select  desired  attribute(s)  [SPACE  BAR]. 

4. 6. 1.3  F10-G0. 

4. 6. 1.4  Select  memh'  ype(s)  [SPACE  BAR]. 

4. 6. 1.5  Check  r_p  c  destination  [ALT-F10]. 

4. 6. 1.6  Print  report  [F10-G0]. 

4.6.2  CATALOGUE 

The  query  lists  members  of  your  local  dictionary  that  contain  a 
specified  catalogue  or  combination  of  catalogues. 

4.6.2. 1  Select  CATALOGUE  from  QUERY  MENU. 

4. 6. 2. 2  Select  query  logic,  EQUAL  or  NOT  EQUAL. 

4. 6. 2. 3  Enter  catalogue  name  or  select  from  look  up  list  [F2]. 

4. 6. 2. 4  Repeat  query  logic  and  catalogue  name  selection,  is  desired. 

4. 6. 2. 5  Check  report  destination  [ALT -F10 ] .  4. 6. 2. 6  Start  query 
[F10] . 

4.6.3  LIST 

This  query  provides  a  list  of  all  member  names  in  your  local  dictionary 
of  a  specified  member  type(s). 

4. 6. 3.1  Select  LIST  from  QUERY  MENU. 

4. 6. 3. 2  Select  member  type(s)  [SPACE  BAR]. 
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4. 6. 3. 3  Check  report  destination  [ALT-F10] . 

4. 6. 3.4  Print  report  [F10-G0]. 

4.6.4  WHAT  CONSTITUTES 

This  query  provides  a  list  of  direct  or  indirect  relationships  FROM  a 
particular  member  in  your  local  dictionary;  a  list  of 
1  children/grandchildren. ' 

4.6.4. 1  Select  WHAT  CONSTITUTES  from  QUERY  MENU. 

4. 6. 4. 2  Choose  DIRECT  or  INDIRECT. 

4. 6.4. 3  Choose  MEMBER  NAME  or  MEMBER  TYPE  order. 

4. 6. 4. 4  Select  member(s)  [SPACE  BAR]. 

4. 6.4. 5  Check  report  destination  [ALT-F10].  4. 6. 4. 6  Print  report 
[F10-G0] . 

4.6.5  WHAT  USES 

This  query  provides  a  list  of  direct  or  indirect  local  dictionary 
relationships  TO  a  particular  member  in  your  local  dictionary;  a  list 
of  'parents/grandparents.' 

4. 6. 5.1  Select  WHAT  USES  from  QUERY  MENU. 

4. 6. 5. 2  Choose  DIRECT  or  INDIRECT. 

4. 6. 5. 3  Choose  MEMBER  NAME  or  MEMBER  TYPE  order. 

4. 6. 5. 4  Select  member(s)  [SPACE  BAR]. 

4. 6. 5. 5  Check  report  destination  [ALT-F10]. 

4. 6. 5. 6  Print  report  [F10-G0]. 

4.6.6  WHAT  IS 

This  query  defines  the  type  of  attribute  or  member  name  you  specify. 

4.6.6. 1  Select  WHAT  IS  from  QUERY  MENU. 

4. 6. 6. 2  Check  report  destination  [ALT-F10]. 

4. 6. 6. 3  Enter  unknown  name. 

4. 6. 6. 4  ENTER. 

4.6.7  WHOSE  ALIAS  IS 
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This  query  lists  all  local  dictionary  members  to  which  the  alias  you 
specify  relates. 

4.6. 7.1  Select  WHOSE  ALIAS  IS  from  QUERY  MENU. 

4. 6. 7. 2  Check  report  destination  [ALT-F10]. 

4. 6. 7. 3  Enter  alias. 

4. 6. 7. 4  Start  query  [F10] . 

4.6.8  WHICH 

This  query  lists  all  local  dictionary  members  and/or  null  members  of  a 
specified  category  or  categories,  satisfying  a  stated  condition  or  set 
of  conditions  (which  member  type  has  a  certain  relationship  with  a 
specified  member) . 

4. 6. 8.1  Select  WHICH  from  QUERY  MENU. 

4. 6.8. 2  Enter  member  type  or  use  look  up  list  [F2]. 

4. 6.8. 3  Enter  relationship  or  use  look  up  list  [F2] . 

4. 6.8.4  Enter  member  name  or  use  look  up  list  [F2]. 

4. 6.8. 5  Check  report  destination  [ALT-F10]. 

4. 6.8. 6  Print  report  [F10-G0]. 

4.7  ARCHIVING 

The  dictionary( ies)  should  be  backed  up  at  the  end  of  any  day  that  the 
dictionary( ies)  has  been  used. 

4.7.1  From  C:\PCDICT,  enter  PCDBACK. 

4.7.2  Make  sure  you  are  in  the  dictionary  that  needs  backing  up.  If 
not,  change  to  that  dictionary. 

4.7.3  Select  BACKUP. 

4.7.4  Select  where  you  want  the  backup  to  reside. 

4.7.5  Enter  name  of  backup  file. 

4.7.6  Run  backup. 

4.7.7  Repeat  for  each  dictionary. 

5.  OUTPUT  PRODUCTS 

Does  not  apply  to  these  procedures. 

6.  RULES 
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Does  not  apply  to  these  procedures. 
7.  EXAMPLES 

Does  not  apply  to  these  procedures. 
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1.  PURPOSE 


The  following  naming  standard  conventions  have  been  developed  to 
support  common  goals  of  standardizing  and  controlling  shared  corporate 
data.  A  set  of  consistently  applied  naming  standards  contributes  to 
these  goals  by  helping  to  ensure  that  the  format  of  shared  data  is  the 
same  across  the  various  using  activities  and  by  reducing  the  amount  of 
redundant  data.  These  in  turn  maximize  the  amount  of  data  that  can  be 
shared  by  different  applications  and  users. 

2.  COMPONENTS/TERMS 

2.1  Adjective  Word 

An  adjective  word  modifies  the  noun  word  in  the  enterprise  model 
components  Function  and  Process  (see  4. 3. 3. 2).  The  adjective  word 
indicates  the  kind  of  activity  being  named  and  the  properties  of  that 
activity. 

2.2  Alias 

An  alias  is  any  name  by  which  the  enterprise  model  component  is  known 
other  than  the  dictionary  member  name  and  the  dictionary  full  business 
name.  Aliases  are  often  name^  that  are  specific  to  a  particular  tool 
or  an  application  and  are  derived  either  from  the  requirements  of  the 
application  or  from  the  restrictions  imposed  by  the  programming 
language  used  to  develop  the  application. 

2.3  Class  Word 

The  class  word  identifies  the  category  or  domain  of  information  to 
which  the  data  belongs,  for  example  ''DATE"  or  "NAME".  It  indicates  the 
type  of  data  that  constitutes  the  enterprise  model  component. 

2.4  Concatenated  Name 

The  concatenated  name  is  a  shortened,  abbreviated  form  of  the  full 
business  name. 

2.5  Full  Business  Name 

The  full  business  name  is  the  clear  text  name  of  the  enterprise 
component. 

2.6  Full  Name 

The  full  name  is  the  attribute  in  the  dictionary  that  is  used  to  record 
the  full  business  name  of  the  enterprise  model  component  for  dictionary 
maintenance  purposes. 

2.7  Member  Name 

The  member  name  is  a  record  in  the  dictionary  that  identifies  a 
dictionary  member.  The  member  name  is  the  key  to  the  dictionary  member 
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record.  For  dictionary  maintenance  purposes,  the  member  name  is  a 
concatenated  name  with  a  two-letter  prefix  attached  to  the  name. 

2.8  Modifier  Word 

Modifier  words  are  used  to  more  fully  describe  a  component  in  the 
dictionary  member  types  Entity,  Domain-Attribute, 
Concatenated-Attribute,  and  Context-Attribute  (see  4. 3. 3. 2). 

2.9  Noun  Word 

A  noun  word  names  the  enterprise  model  component  Function  and  is  used 
in  the  name  of  the  enterprise  model  component  Process  in  conjunction 
with  the  verb  word  (see  4. 3. 3. 2). 

2.10  Prime  Word 

The  prime  word  is  used  in  the  dictionary  member  types  Entity, 
Context-Attribute,  and  Concatenated-Attribute  to  identify  the 
enterprise  model  component  about  which  information  is  being  kept.  The 
components  identified  by  the  prime  words  are  strictly  logical;  that  is, 
they  belong  to  the  information  architecture  and  not  to  any  particular 
application  or  data  base.  In  this  way  the  prime  word  relates  an 
enterprise  model  component,  through  the  logical  structure  of  the  name, 
to  the  logical  architecture  of  the  enterprise. 

2.11  Relationship  Word 

Relationship  words  are  words  that  define  an  association  between  two 
enterprise  model  components. 

2.12  Verb  Word 

Verb  words  identify  the  enterprise  model  component  Process.  Verb  words 
identify  what  the  enterprise  does,  the  actions  that  make  up  its 
activities. 

3.  INPUT  PRODUCTS 

The  input  products  to  be  named  are  the  enterprise  model  components 
derived  from  the  Conceptual  Information  Architecture  and  the  Logical 
Information  Architecture. 

4.  GENERAL  PROCEDURES 

4.1  Introduction 

The  procedures  and  rules  used  to  develop  enterprise  model  component 
names  are  determined  in  part  by  the  tool  being  used  when  the  name  is 
created.  The  names,  however,  must  be  mapped  across  all  the  tools  used. 
Thus,  a  general  set  of  procedures  has  been  provided  that  is  not  limited 
by  any  specific  tool,  followed  by  procedures  specific  to  each  tool  used 
to  develop  the  DLA  enterprise  model. 

4.2  General  rules 
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4.2.1  The  name  shall  identify  one  and  only  one  enterprise  model 
component. 

4.2.2  The  name  shall  not  be  the  same  as  any  other  name  in  the 
dictionary. 

4.2.3  Prime  words  and  class  words  used  to  name  entities  and  attributes 
shall  be  selected  from  lists  of  approved  prime  words  and  class  words. 
Class  words  are  reserved  and  shall  not  be  used  as  prime  words, 
modifiers,  or  qualifiers. 

4.3  Generic  procedures 

The  procedures  specified  in  section  4.3  will,  if  followed,  help  ensure 
that  all  abbreviations,  all  words,  and  all  names  used  in  the  enterprise 
model  are  unique.  For  clarity,  the  procedures  are  provided  in  outline 
form  in  the  following  table: 

ENTERPRISE  MODEL  COMPONENT  (EMC)  NAME  DEVELOPMENT 

(4.3.1)  Research  the  EMC  name 

(4. 3. 1.1)  Check  lists  of  approved  names 

(4. 3. 1.1.1)  Check  for  synonyms 

(4. 3. 1.1. 2)  Use  any  approved  names  that 
name  the  EMC 

(4.3.2)  Establish  a  full  business  name 

(4. 3. 2.1)  Describe  the  EMC 

(4. 3. 2. 2)  Evaluate  the  EMC  description 

(4. 3. 2. 2.1)  Identify  key  words 

(4. 3. 2. 2. 2)  Verify  correct  use  of  words 

(4. 3. 2. 2. 3)  Change  verbs  to  nouns  if 
required 

(4. 3. 2. 2. 4)  Spell  out  any  abbreviations 
and  acronyms 

(4. 3. 2. 3)  Check  approved-word  lists 

(4. 3. 2. 4)  Check  name  length 

(4.3.3)  Establish  a  concatenated  name  for  the  EMC 

(4.3.3. 1)  Evaluate  the  full  business  name 

(4. 3. 3. 2)  Change  name  to  follow  format  rules 

(4. 3. 3. 3)  Abbreviate  words 

(4. 3. 3. 3.1)  Check  lists  of  abbreviations 

(4. 3. 3. 3. 2)  Create  new  abbreviations 

(4. 3. 3.4)  Check  name  length 

(4.3.4)  Add  EMC  name  to  dictionary 

4.3.1  Research  enterprise  model  component  name 

The  enterprise  model  component  name  is  the  name  assigned  to  the 
enterprise  model  component.  The  names,  the  words,  and  the 
abbreviations  that  make  up  the  names  are  maintained  in  the  enterprise 
data  dictionary. 

4. 3. 1.1  Check  list  of  existing  approved  names  for  enterprise  model 
components. 
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4. 3. 1.1.1  Watch  for  possible  synonyms,  i.e.  different  names  that 
describe  the  same  component  (for  example  "customer"  and  "consumer"  may 
be  synonymous).  Names  are  synonymous  in  their  specific  usage  or 
distinguishing  characteristics  more  than  in  their  definitions  and  the 
judgment  of  the  functional  user  may  be  required  to  determine  if  two 
names  are  synonymous. 

4. 3. 1.1. 2  If  a  name  is  located  on  the  list  that  can  be  used  to  name 
the  component,  that  name  shall  be  used;  otherwise,  the  procedures 
outlined  in  this  appendix  shall  be  used  to  create  a  new  name.  If  a 
name  is  not  located  that  names  the  component,  a  new  name  shall  be 
developed. 

4.3.2  Establish  a  full  business  name  for  the  enterprise  model 
component 

The  full  business  name  is  the  clear  text  English  name  of  the  component 
that  clearly  describes  the  component.  In  the  full  business  name,  the 
word  order  shall  be  the  same  as  in  common  English  usage.  The  name 
shall  contain  no  abbreviations  and  all  acronyms  shall  be  spelled  out. 

4.3.2. 1  The  first  step  in  naming  an  enterprise  model  component  is  to 
develop  a  clear,  concise,  and  accurate  description  of  the  component. 
Describe  the  component  by  its  distinguishing  characteristics  in  a  plain 
English  sentence  or  phrase.  Avoid  adding  unnecessary  words  to  the 
description. 

4. 3. 2. 2  Evaluate  the  enterprise  model  component  description 

4. 3. 2. 2.1  Identify  the  grammatically  key  words  used  in  the  description 
and  the  words  that  are  required  for  the  component  as  shown  in  4. 3. 3. 2 
(for  example,  prime  words,  class  words,  relationship  words,  etc.,  as 
defined  in  section  2).  Some  words  may  be  hyphenated  into  terms  that 
will  function  as  one  word  (for  example,  LEGAL-ENTITY  or  LINE-ITEM).  By 
creating  a  new  word  out  of  two  words,  unique  prime  words  may  be  created 
that  both  reflect  normal  business  usage  and  that  satisfy  the 
requirements  of  the  data  model.  This  procedure  may  also  allow  the  use 
of  reserved  words  in  unreserved  modifiers.  In  addition,  when  acronyms 
are  fully  spelled  out,  the  words  that  comprise  the  acronym  should  be 
separated  by  hyphens  in  order  to  identify  those  words  that  form  the 
acronym.  Verify  that  the  words  are  unambiguous  and  appropriate  to  the 
enterprise  model  component. 

4. 3. 2. 2. 2  For  entities  and  attributes,  verify  that  prime  words  and 
class  words  are  used  correctly  and  that  only  one  prime  word  and/or  one 
class  word  is  used  in  the  description.  If  more  than  one  prime  word  is 
used,  this  is  a  good  indication  that  the  description  may  be  describing 
more  than  one  entity  and  the  entity  may  require  further  analysis. 

4. 3. 2. 2. 3  If  required  by  the  rules  for  the  component  name  (see 

4. 3. 3. 2. 8,  for  example),  change  verbs  to  nouns  (for  example,  the  verb 
"acquire"  could  be  changed  to  "acquisition"  or  the  verb  "process"  could 
be  changed  to  the  gerund  form  "processing"). 
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4. 3. 2. 2. 4  Spell  out  any  abbreviations  or  acronyms. 

4. 3. 2. 3  Check  approved-word  lists 

Look  up  the  words  that  make  up  the  name  on  the  lists  of  approved  words. 
Wherever  possible,  the  words  on  the  approved-word  lists  should  be 
substituted  for  the  words  initially  used  in  the  name,  but  be  careful  to 
avoid  synonyms  and  homonyms. 

4. 3. 2. 3.1  Any  new  words  required  to  name  the  component  will  be  added 
to  the  list  of  approved  words  when  the  name  is  added  to  the  dictionary 
(see  4.3.4). 

4. 3.2.4  Check  name  length 

The  maximum  allowed  length  of  the  name  may  depend  on  the  tool  being 
used.  If  the  name  exceeds  the  maximum  allowed  length,  remove  enough 
unimportant  words  to  reduce  the  name  to  the  allowed  length. 

4.3.3  Establish  a  concatenated  name  for  the  enterprise  model  component 

The  concatenated  name  is  a  shortened,  abbreviated  form  of  the  full 
business  name  that  conforms  to  the  specified  rules  for  length  and  word 
order  for  the  component  name. 

4. 3. 3.1  Evaluate  the  full  business  name  (see  4.3.2) 

Remove  any  unnecessary  words  such  as  articles,  connectors,  and 
prepositions. 

4. 3. 3. 2  Check  name  against  format  rules  for  that  component  name 

Verify  that  only  allowed  words  such  as  reserved  words,  nouns,  or  verbs 
are  used  in  the  name.  Arrange  the  words  in  the  order  required  for  that 
component  name,  separate  all  words  with  a  hyphen,  and  add  any  required 
prefixes.  Rules  specific  to  each  member  type  follow  the  table.  For 
further  definition  and  elaboration  see  the  definition  for  the  member 
types  maintained  in  the  data  dictionary. 

MEMBER  TYPE  NAME  FORMATS* 


MEMBER  TYPE 
Domain-Attribute 
Entity 

Context-Attribute 

Concatenated-Attribute 

Relationship 


NAME  FORMAT 

(Modif ier(s))-Class  word- (Qua  1  if ier(s) ) 

Prime  word-(Modif ier(s) ) 

Prime  word-(Modif ier(s) )-Class-word- 
(Qualif ier(s) ) 

Prime  word-(Modif ier(s) )-Class-word- 
(Qual if ier(s) ) 

Entity  name-Relationship  word-Entity  name 
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Dataflow 


Source  name-Verb  word-Destination  name 


External -Agent 
Function 
Process 
User view 

Information-Requirement 
Objective 

Critical -Success-Factor 
Subject-Area 
*0ptional  words  are  indicated  by  parentheses. 

4. 3. 3. 2.1  Member  type  Domain-Attribute 

A  Domain-Attribute  identifies  a  common  set  of  formats  and  values  for 
one  or  more  Context  and/or  Concatenated  Attributes.  A  Domain-Attribute 
name  shall  have  one  class  word  (see  2.3)  selected  from  a  list  of 
reserved  class  words  and  may  contain  one  or  more  optional  modifiers. 

The  class  word  will  be  a  noun  that  indicates  the  type  of  data  that 
forms  the  enterprise  model  component.  The  modifiers  will  help  further 
describe  the  data  and  shall  precede  the  class  word  in  the 
Domain-Attribute  word  order.  In  addition,  for  quantitative  data, 
optional  qualifiers  that  describe  the  unit  of  measure  used  by  the  data 
may  be  added  as  a  modifier  to  the  end  of  the  Domain-Attribute  name. 


External 
Noun 
Verb  word 


4. 3. 3. 2. 2  Member  type  Entity 


Agent-Verb  word-Destination  name 
word(s)-(Ad jective  word(s)) 

-Noun  word(s)- (Ad jective  word(s)) 
Abbreviated  word(s) 

Abbreviated  word(s) 

Abbreviated  word(s) 

Abbreviated  word(s) 

Abbreviated  word(s) 


An  entity  represents  a  person,  place,  thing,  concept  or  event  about 
which  the  enterprise  requires  information.  An  entity  name  shall  have 
one  prime  word  (see  2.10)  selected  from  a  list  of  prime  words  and  may 
contain  one  or  more  optional  modifiers.  The  prime  word  shall  be  a  noun 
in  the  singular  form.  The  modifiers  help  further  describe  the  entity. 

4. 3. 3. 2. 3  Member  type  Context-Attribute 


A  Context-Attribute  is  any  aspect,  quality,  characteristic,  or 
descriptor  of  an  entity.  In  its  construction,  the  Context-Attribute  is 
a  combination  of  the  Prime  word-Modifier  element  from  entities  and  the 
Modifier-Class  word  element  from  Domain-Attributes. 


4. 3. 3. 2. 4  Member  type  Concatenated-Attribute 

A  Concatenated-Attribute  is  a  set,  or  group,  of  Context-Attributes  (see 
4. 3. 3. 2. 3)  that  may  be  referred  to  as  a  unit. 

4. 3. 3. 2. 5  Member  type  Relationship 
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A  Relationship  is  an  action  which  one  entity  takes  upon  or  receives 
from  another  entity  as  shown  on  the  applicable  entity  relationship 
diagrams.  The  Relationship  name  contains  the  names  of  the  related 
entities  separated  by  a  word  or  term  that  describes  the  relationship. 
The  word  describing  the  relationship  describes  an  action  and  so  should 
be  in  the  verb  form.  The  relationship  word  should  be  in  the  present 
tense.  Relationship  words  in  the  active  voice  will  often  have  a 
converse  passive  voice.  For  example,  CUSTOMER-PURCHASES-ITEM  may  have 
a  converse  relationship  named  ITEM-IS-PURCHASED-BY-CUSTOMER. 

4. 3. 3. 2. 6  Member  type  Dataflow 

Dataflows  are  composed  of  information  about  entities  and  attributes. 
They  represent  information  about  one  or  more  entities  which  flows  into 
and  out  of  External-Agents  and  to  and  from  Processes  as  represented  on 
the  applicable  dataflow  diagrams.  The  first  word  in  the  Dataflow  name 
shall  name  the  immediate  source  of  the  data  and  the  last  word  shall 
name  the  recipient  or  destination  of  the  data.  The  source  and 
destination  names  shall  be  separated  by  the  name  of  the  Dataflow.  This 
name  shall  be  a  verb  since  it  names  an  action  and  should  be  in  the 
present  tense. 

4. 3. 3. 2. 7  Member  type  External-agent 

An  External -Agent  is  an  organization  that  is  external  to  the 
enterprise.  The  organization  can  be  a  source  of  data  which  flows  into 
processes,  and  the  organization  can  receive  data  from  the  processes  as 
represented  on  the  dataflow  diagrams.  The  first  word  in  the  name  shall 
be  a  noun  that  names  the  External-Agent;  the  second  word  shall  be  a 
verb  that  names  the  flow  of  data;  and  the  third  word  shall  be  a  noun 
that  names  the  destination  of  the  data. 

4. 3. 3. 2.8  Member  type  Function 

A  Function  is  a  concept  that  embodies  a  major,  high-level  activity  of 
an  enterprise,  comprising  a  broad  group  of  processes  that  together 
completely  support  one  aspect  of  furthering  a  mission  of  the 
enterprise.  The  function  is  named  by  a  noun  and  optional  adjectives 
that  further  describe  the  function.  The  noun  may  be  derived  by 
converting  a  verb  to  its  gerund  form,  for  example,  "PURCHASE"  may  be 
converted  to  "PURCHASING". 

4. 3. 3. 2. 9  Member  type  Process 

A  Process  is  a  low-level  activity  or  group  of  activities  that  starts  or 
stops  and  is  repeatedly  executed.  Decomposing  a  Function  yields  its 
component  Processes.  The  Process  name  includes  a  verb  that  names  the 
process,  a  noun  that  names  the  object  of  the  verb  and  additional 
adjectives  that  further  describe  the  process. 

4.3.3.2.10  Member  types  Userview,  Information-Requirement,  Objective, 
Critical-Success-Factor,  and  Subject-Area 

These  member  types  have  no  format  specifically  defined  for  dictionary 
maintenance.  The  name  structures  are  defined  only  as  abbreviated  words 
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in  order  to  describe  their  dictionary  member  name  format;  otherwise  the 
format  will  be  determined  by  the  requirements  of  the  enterprise  model 
component  itself. 

4. 3. 3. 3  Abbreviate  words  as  required 

All  words  longer  than  five  characters  shall  be  abbreviated.  Words  less 
than  five  characters  in  length  should  be  fully  spelled  out  although 
this  is  not  a  requirement.  Abbreviations  may  be  less  than  five 
characters  long. 

4. 3. 3. 3.1  Lists  of  standard  abbreviations 

Reserved  words  will  already  be  recorded  in  the  data  dictionary  with  an 
approved  abbreviation.  Also,  non-reserved  words  that  have  been  used  in 
other  component  names  will  be  similarly  recorded.  The  first  step  is  to 
look  up  each  word  on  these  lists  to  determine  if  it  has  already  been 
abbreviated.  If  it  has  already  been  abbreviated,  then  this  approved 
abbreviation  shall  be  used.  Note:  Different  forms  of  the  same  word 
will  have  different  abbreviations,  for  example  the  abbreviation  of  an 
"ing"  gerund  form  of  a  verb  will  end  with  the  letter  "g"  and  this  would 
not  be  used  in  the  abbreviation  of  the  present  indicative  tense.  Be 
sure  that  the  abbreviation  is  accurate  for  the  form  of  the  word  you  are 
using.  If  no  approved  abbreviations  exist  for  the  words  in  the  name, 
then  create  a  new  abbreviation  according  to  the  following  guidelines. 

4. 3. 3. 3. 2  Creating  a  new  abbreviation 

(1)  The  meaning  of  the  abbreviation  should  be  as  intuitively 
obvious  to  the  user  as  possible. 

(2)  Use  a  short  form  of  the  word  if  it  is  easily  recognized. 

(3)  Use  standard  suffix  abbreviations  (ing=g,  ment=mt, 
able=bl,  tion=tn). 

(4)  Drop  one  letter  of  any  double  consonants. 

(5)  Drop  vowels  from  right  to  left,  unless: 

(a)  The  clear  meaning  of  the  abbreviation  is  lost. 

(b)  The  vowel  is  the  first  letter  of  the  word. 

(c)  The  word  begins  with  a  diphthong  (au,  ai,  ei,  ou, 
etc.). 

(6)  Drop  consonants  from  right  to  left  until  the  length  limit 
is  reached,  unless: 

(a)  The  clear  meaning  of  the  abbreviation  is  lost. 

(b)  The  consonant  is  the  first  letter  of  the  word. 

(7)  Do  not  use  abbreviations  that  are  words  in  their  own  right 
(PART  for  partition). 

(8)  Do  not  use  abbreviations  that  are  common  abbreviations  for 
other  words  outside  the  organization  (COD  is  normally  used 
for  Cash  on  Delivery). 

(9)  A  word  shall  have  only  one  abbreviation  and  a  particular 
abbreviation  shall  be  used  for  only  one  word. 
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4. 3. 3. 4  Check  name  length 

The  maximum  allowed  length  of  the  name  may  depend  on  the  tool  being 
used.  If  the  name  exceeds  the  maximum  allowed  length,  remove  enough 
unnecessary  words  to  reduce  the  name  to  the  allowed  length. 

4.3.4  Add  enterprise  model  component  name  to  dictionary 

Add  the  enterprise  model  component  name  and  its  component  words  to  the 
data  dictionary  and  word  lists. 

4.4  Procedures  specific  to  recording  dictionary  member  names  and  words 
in  PC  DICTIONARY 

These  instructions  describe  how  to  record  new  names  and  words  in  PC 
DICTIONARY.  The  words  to  be  added  are  those  words  that  are  used  in 
enterprise  model  component  names  when  new  names  are  created.  By 
maintaining  a  record  of  the  words  used  in  names,  a  list  of  approved 
words  is  kept  that  can  be  used  to  create  new  names.  This  effectively 
reduces  the  number  of  words  that  will  be  used  in  creating  component 
names,  thereby  reducing  the  number  of  synonymous  words  and  names. 

4.4.1  Adding  dictionary  member  names 

The  following  paragraphs  provide  the  rules  and  conventions  developed 
for  adding  dictionary  names  to  PC  DICTIONARY. 

4. 4. 1.1  General  rules 

4. 4. 1.1.1  Dictionary  member  name 

The  dictionary  member  name  is  the  concatenated  name  of  the  enterprise 
model  component  (see  2.4  and  2.7). 

RULE:  The  maximum  allowed  length  for  a  member  name  in  PC 

DICTIONARY  is  32  characters,  including  any  prefixes  and 
hyphens. 

RULE:  There  shall  be  no  blank  spaces  in  the  member  name;  if 

the  name  contains  more  than  one  word,  the  words  shall  be 
separated  by  hyphens.  Prefixes  such  as  "pre"  or  "non" 
should  be  added  to  the  word  they  modify  rather  than 
separated  by  a  hyphen  so  the  prefix  will  not  appear  to 
form  a  separate  word. 

RULE:  Abbreviations  used  in  the  member  name  shall  be  unique. 
The  maximum  allowed  length  for  an  abbreviation  is  five 
characters. 

4. 4. 1.1. 2  Dictionary  ful 1  name 

The  dictionary  full  name  is  the  unabbreviated,  plain  English, 
descriptive  name  of  the  enterprise  model  component  (see  2.5  and  2.6). 
The  full  name  is  the  authoritative  name  maintained  in  the  dictionary; 
that  is,  the  full  name  completely  describes  the  component,  and  any 
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other  names  used  to  name  the  component  are  regarded  as  aliases  of  the 
full  name  because  the  constraints  and  format  requirements  placed  upon 
the  aliases  generate  duplicate  and/or  less  meaningful  names. 

RULE:  The  maximum  allowed  length  in  PC  DICTIONARY  for  a  full 
name  is  254  characters. 

RULE:  The  full  name  shall  contain  no  abbreviations  or 
acronyms. 

RULE:  Any  single  word  composed  of  multiple  words  separated  by 
hyphens  shall  also  have  the  words  separated  by  hyphens 
in  the  full  name. 

RULE:  The  full  name  shall  not  contain  any  prefixes  used  as 
identifiers  (see  4. 4. 1.2,  4.5.4,  and  4.5.5). 

4. 4. 1.2  Enterprise  model  component  member  types 

When  dictionary  names  are  recorded  in  PC  DICTIONARY,  the  following 
prefixes  shall  be  added  to  the  dictionary  member  name  and  separated 
■from  the  name  with  a  hyphen: 


Domain-Attribute 

DM 

Entity 

EN 

Context-Attribute 

CT 

Concatenated-Attribute 

CC 

Relationship 

RL 

Dataflow 

DF 

External-Agent 

EA 

Function 

FN 

Process 

PR 

Userview 

UV 

Information-Requirement 

IR 

Objective 

OB 

Critical-Success-Factor 

CF 

Subject-Area 

SA 

4.4.2  Adding  a  new  word  in  PC  DICTIONARY  under  member  type  WORD 

Word  lists  for  the  Contractor  Profile  Pilot  Project  are  maintained  in 
PC  DICTIONARY  in  the  dictionary  named  DLAADMIN  under  two  member  types: 
WORD  and  ACRONYM.  The  member  type  WORD  is  the  basic  list  of  words  that 
have  been  used  in  component  names.  All  terms  made  up  of  hyphenated 
words  shall  be  recorded  in  the  dictionary  as  new  words.  Each  word  in 
the  member  type  WORD  shall  be  prefixed  with  the  word  "WORD". 

4. 4. 2.1  From  the  main  menu  in  PC  DICTIONARY  select: 

"A.. DATA  ENTRY" 

4. 4. 2. 2  Enter  the  new  word  as  a  member  name  prefixed  with  the  word 
"WORD"  and  a  hyphen  (e.g.,  WORD-MANAGEMENT). 

RULE:  The  maximum  allowed  length  for  a  member  name  in  PC 

DICTIONARY  is  32  characters,  including  the  prefix  "WORD" 
and  hyphens. 
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RULE:  There  shall  be  no  blank  spaces  in  the  member  name;  if 

the  name  contains  more  than  one  word,  the  words  shall  be 
separated  by  hyphens.  Prefixes  such  as  "pre"  or  "non" 
should  be  added  to  the  word  they  modify  rather  than 
separated  by  a  hyphen  so  the  prefix  will  not  appear  to 
form  a  separate  word. 

4.4.2. 3  Enter  the  member  type  "WORD" 

4. 4. 2. 4  Adding  attributes 

4. 4. 2. 4.1  Add  ABBREVIATION 

The  abbreviation  should  be  formed  in  accordance  with  the  procedures 
given  in  4. 3. 3. 3. 2.  All  words  shall  have  an  ABBREVIATION  attribute 
recorded,  even  if  the  abbreviation  is  the  word  itself. 

RULE:  The  abbreviation  shall  be  unique. 

RULE:  The  maximum  allowed  length  for  the  abbreviation  is  five 
characters. 

4. 4. 2. 4. 2  Add  ALIAS 

Add  any  aliases  that  may  exist  for  this  word.  This  attribute  is 
optional  since  there  may  not  be  any  aliases  or  synonyms  for  the  word. 
IEW  aliases  are  listed  on  the  line  reserved  for  the  IEW  alias.  If 
|  synonyms  exist  for  the  word,  they  should  be  listed  on  blank  lines  with 
no  classifiers.  This  will  allow  the  listing  of  multiple  synonyms  for 
any  one  word.  Plural  forms  of  words  that  are  spelled  differently  from 
the  singular  form  may  also  be  entered  on  the  line  reserved  for  plurals. 
This  will  capture  the  plural  form  as  used  by  the  system  without  having 
to  create  a  new  dictionary  member  with  a  unique  abbreviation.  All 
aliases  and  synonyms  for  any  word  shall  be  recorded. 

RULE:  The  maximum  allowed  length  in  PC  DICTIONARY  for  an  alias 
is  32  characters,  although  a  shorter  length  may  be 
required  by  the  programming  language  or  application 
which  uses  the  synonym. 

4. 4. 2. 4. 3  Add  CATALOGUE 

The  CATALOGUE  attribute  is  used  to  indicate  whether  the  word  is  a  prime 
word,  class  word,  or  modifier.  By  listing  these  as  catalogue 
attributes,  lists  of  prime  words,  class  words,  or  modifiers  may  be 
generated.  Reserved  words  have  a  catalogue  attribute  of  CLASS.  All 
others  have  an  attribute  of  PRIME  and/or  MODIFIER. 

RULE:  Each  class  word  shall  have  only  the  catalogue  CLASS 
since  CLASS  is  exclusive.  All  other  words  shall  be 
recorded  as  PRIME  and/or  MODIFIER. 

4. 4. 2. 4. 4  Add  FULL-NAME 
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The  full  name  is  the  word  fully  spelled  out.  Normally  the  full  name 
will  be  the  same  as  the  member  name  except  it  will  not  contain  the 
prefix  WORD.  Each  word  shall  have  a  full  name  recorded. 

RULE:  The  maximum  allowed  length  is  254  characters. 

RULE:  The  full  name  shall  contain  no  abbrevieL i^n:  - 
acronyms. 

RULE:  Any  single  word  composed  of  multiple  words  separated  by 
hyphens  shall  have  the  words  separated  by  hyphens  in  the 
full  name. 

RULE:  The  full  name  shall  not  contain  the  prefix  WORD. 

4. 4. 2. 4. 5  Add  SOURCE 

The  source  is  a  short  description  of  the  activity  that  originated  the 
enterprise  model  component  containing  the  name  that  uses  the  word. 

There  may  be  multiple  sources  of  an  enterprise  model  component  name;  in 
this  case  each  should  be  listed.  Source  is  not  a  required  attribute. 

4. 4. 2. 4. 6  Add  DESCRIPTION 

If  necessary,  a  brief  description  of  the  word  should  be  added.  For 
prime  words  and  class  words  the  description  should  be  a  concise  and 
complete  definition  of  the  word.  Descriptions  are  optional  for 
modifiers  (although  a  description  will  help  prevent  synonyms)  and 
required  for  all  prime  words  and  class  words. 

4. 4. 2. 4. 7  Add  REFERENCE 

The  attribute  REFERENCE  can  be  used  to  record  other  pertinent  notes  and 

comments  that  could  not  be  included  as  other  attributes. 

4.4.3  Adding  a  new  word  in  PC  DICTIONARY  under  member  type  ACRONYM 

The  member  type  ACRONYM  was  developed  to  list  acronyms  used  in 
component  names.  It  became  necessary  to  provide  a  member  type  for 
acronyms  separate  from  a  member  type  for  words  for  several  reasons. 
First,  many  acronyms  are  also  homonyms  of  actual  words  (for  example, 

MAP  (for  "Military  Aid  Program")  and  "map")  and  the  only  way  to  record 
the  difference  in  PC  DICTIONARY  is  through  the  use  of  a  different 
member  type  for  acronyms.  Second,  many  acronyms,  when  fully  spelled 
out,  exceed  the  maximum  allowable  character  length  for  names.  These 
lengthy  names  cannot  be  recorded  in  PC  DICTIONARY  or  used  in  certain 
applications  unless  an  acronym  is  used  that  reduces  the  total  number  of 
characters  in  a  name.  Third,  some  acronyms  may  use  reserved  words 
within  the  acronym.  If  the  acronym  is  spelled  out  in  a  name,  it  may  be 

that  the  reserved  words  are  being  used  in  an  illegal  manner--that  is, 

they  are  used  not  as  reserved  words  but  as  modifiers.  The  best  way  to 
avoid  this  conflict  is  to  concatenate  the  words  that  form  the  acronym 
into  a  term  that  is  treated  as  one  word.  The  term  is  then  verified, 
stored,  and  searched  as  one  word  rather  than  as  multiple  words.  All 
acronyms  shall  be  spelled  out  fully  in  the  full  business  name  attribute 
for  the  component  name. 

4.4. 3.1  From  the  main  menu  in  PC  DICTIONARY  select: 
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A.. DATA  ENTRY 


4. 4. 3. 2  Enter  the  new  acronym  as  a  member  n-me  prefixed  with  the 
letters  ACR  and  a  hyphen  (e.g.,  ACR-CAGE).  Enter  the  acronym  as  it  is 
normally  used.  Do  not  spell  out  any  words  unless  they  are  normally 
spelled  out  in  the  acronym  (e.g.,  ACR-I-AND-S) . 

RULE:  The  maximum  allowed  length  for  a  member  name  in  PC 

DICTIONARY  is  32  characters,  including  the  prefix  ACR 
and  hyphens. 

RULE:  There  shall  be  no  blank  spaces  in  the  member  name;  if 

the  name  contains  more  than  one  word,  the  words  shall  be 
separated  by  hyphens. 

4. 4. 3. 3  Enter  the  member  type  ACRONYM 

4. 4. 3. 4  Adding  attributes 

4.4. 3.4.1  Add  ALIAS 

Add  any  aliases  that  may  exist  for  this  acronym.  This  attribute  is 
optional  since  there  may  not  be  any  aliases  or  synonyms  for  this 
acronym.  IEW  aliases  are  listed  on  the  line  reserved  for  the  IEW 
alias.  If  synonyms  exist  for  the  acronym,  they  should  be  listed  on 
blank  lines  with  no  classifiers.  This  will  allow  the  listing  of 
multiple  synonyms  for  any  one  word.  All  aliases  and  synonyms  for  any 
word  shall  be  recorded. 

RULE:  The  maximum  allowed  length  in  PC  DICTIONARY  for  an  alias 
is  32  characters,  although  the  length  is  effectively 
determined  by  the  programming  language  or  application 
which  uses  the  synonym. 

4.4. 3.4.2  Add  CATALOGUE 

The  CATALOGUE  attribute  is  used  to  indicate  whether  the  acronym  is  a 
prime  word  or  a  modifier.  A  class  word  will  never,  by  definition,  be 
an  acronym. 

RULE:  Each  acronym  will  have  only  the  catalogue  attributes 
PRIME  and/or  MODIFIER. 

4.4. 3.4. 3  Add  FULL  NAME 

The  full  name  is  the  acronym  fully  spelled  out  with  all  words  separated 
by  hyphens. 

RULE:  The  maximum  allowed  length  is  254  characters,  including 
hyphens. 

RULE:  The  full  name  shall  contain  no  abbreviations  or 
acronyms. 

RULE:  All  words  (for  the  member  type  acronym)  in  the  full  name 
shall  be  separated  by  hyphens. 

RULE:  The  full  name  shall  not  contain  the  prefix  ACR. 
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4. 4. 3. 4. 4  Add  SOURCE 


The  source  is  a  short  description  of  the  activity  that  originated  the 
enterprise  model  component  name  containing  the  acronym.  There  may  be 
multiple  sources  of  the  enterprise  model  component  name;  in  this  case 
each  should  be  listed.  Source  is  not  a  required  attribute. 

4.4. 3.4. 5  Add  DESCRIPTION 

If  necessary,  a  brief  description  of  the  acronym  should  be  added. 
Descriptions  are  optional  for  modifiers  (although  a  definition  will 
help  prevent  synonyms)  and  required  for  prime  words. 

4.4. 3.4. 6  Add  REFERENCE 

The  attribute  REFERENCE  can  be  used  to  record  other  pertinent  notes  and 
comments  that  could  not  be  included  as  other  attributes. 

4.4.4  PC  DICTIONARY  reports  and  queries 

Names,  words,  and  acronyms,  together  with  their  attributes,  may  be 
researched  in  PC  DICTIONARY  using  the  following  procedures. 

4.4.4. 1  Selected  member  types,  selected  member  names,  and  all 
attributes 

The  following  procedure  will  provide  reports  of  selected  member  types, 
selected  member  names  and  all  of  their  attributes.  This  report  is 
useful  for  generating  complete  documentation  on  all  words  and  acronyms 
with  their  attributes. 

4. 4. 4. 1.1  From  the  main  menu,  select: 

"B.. Report  Menu" 

4. 4. 4. 1.2  From  the  report  menu,  select: 

"C.. Member  Definition" 

4. 4. 4. 1.3  Select  the  members  to  be  reported 

4. 4. 4. 2  Member  name,  member  type,  and  selected  attributes 

The  following  procedure  will  provide  reports  of  selected  attributes  of 
all  members  within  selected  member  types.  This  report  is  useful  for 
generating  lists  of  words  or  acronyms  showing  their  abbreviations,  full 
names,  and  any  other  desired  attributes. 

4. 4. 4. 2.1  From  the  main  menu,  select: 

"C. .Query  Menu" 

4. 4. 4. 2. 2  From  the  query  menu,  select: 
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A. .Glossary 


4. 4. 4. 2. 3  Select  the  attributes  to  be  reported 

4. 4. 4. 2. 4  Select  the  member  types  to  report  attributes  from 

4. 4. 4. 3  Catalogue 

The  following  procedure  will  provide  reports  of  selected  catalogues  for 
all  members  of  the  dictionary.  This  report  is  useful  for  generating 
lists  of  prime  words,  class  words,  and  modifiers. 

4. 4. 4. 3.1  From  the  main  menu,  select: 

"C.  .Query  Menu1' 

4. 4. 4. 3. 2  From  the  query  menu,  select: 

"B. .Catalogue" 

4. 4. 4. 3. 3  Select  all  members  whose  catalogue  equals  PRIME,  CLASS,  or 
MODIFIER.  Since  class  words  are  reserved  they  will  only  have  the 
catalogue  CLASS;  other  words  may  have  catalogues  of  both  PRIME  and 
MODIFIER. 

4.4.5  Name  lists 

The  following  procedure  will  provide  a  list  of  names  maintained  in  PC 
DICTIONARY  with  any  selected  attributes.  For  the  Contractor  Profile 
Pilot  Project,  this  information  is  maintained  in  the  dictionary  named 
DLALOG. 

4.4.5. 1  From  the  main  menu,  select: 

"C.. Query  menu" 

4. 4. 5. 2  From  the  query  menu,  select: 

"A. .Glossary" 

4.4. 5. 3  Select  any  desired  attributes  (for  example,  ABBREVIATION  and 
FULL-NAME). 

4.4. 5.4  Select  the  desired  member  type  (for  a  complete  list  of  all 
names,  all  member  types  must  be  selected). 

4. 4. 5. 5  The  list  will  be  printed  in  alphabetical  order  beginning  with 
the  assigned  two- letter  member  type  code. 

4.5  Procedures  specific  to  adding  enterprise  model  component  names  in 
KnowledgeWare' s  Information  Engineering  Workbench  (IEW) 

The  following  procedures  provide  the  conventions  to  be  followed  when 
adding  enterprise  model  component  names  to  an  information  model  in  IEW. 
The  conventions  specified  in  sections  4.2  and  4.3  shall  be  followed 


437 


when  creating  new  names.  When  adding  enterprise  model  component  names 
to  IEW,  either  the  approved  abbreviated  member  name  or  the  full  name 
may  be  used,  except  the  two- letter  prefix  on  the  abbreviated  member 
name  shall  not  be  a  part  of  the  name  entered  in  IEW.  If  a  name  is 
added  to  IEW  that  is  not  an  approved  dictionary  member  name  and  that 
does  not  follow  the  format  specified  for  that  member  name,  then  the 
unique  IEW  name  shall  be  entered  in  the  dictionary  as  an  IEW  alias.  In 
addition,  any  IEW  Functions  or  Processes  that  require 
hierarchy/sequence  identifiers  (see  4.5.4  and  4.5.5)  shall  be  recorded 
in  the  dictionary  with  the  identifier  as  an  IEW  alias. 

4.5.1  Enterprise  model  entities 

When  adding  entity  names  to  IEW  models,  the  format  shall  be  as 
specified  for  entities  in  4. 3. 3. 2  and  4. 3. 3. 2. 2.  All  letters  shall  be 
upper  case. 

4.5.2  Enterprise  model  attributes 

When  adding  attribute  names  to  IEW  models,  the  format  shall  be  as 
specified  in  4. 3. 3. 2,  4. 3. 3. 2.1,  4. 3. 3. 2. 3,  and  4. 3. 3. 2. 4.  All  letters 
shall  be  upper  case.  When  reports  are  generated  by  IEW,  the  attribute 
name  and  associated  entity  name  will  be  automatically  separated  by  a 
period  by  IEW. 

4.5.3  Enterprise  model  relationships 

When  adding  relationship  names  to  IEW  models,  the  format  shall  be  as 
specified  in  4. 3. 3. 2  and  4. 3. 3. 2. 5.  The  entity  names  shall  be  upper 
case  and  the  relationship  verb-phrase  shall  be  lower  case  with  the 
words  separated  by  hyphens,  using  the  approved  abbreviations.  When 
reports  are  generated  by  IEW,  the  verb-phrase  will  be  separated  from 
the  entity  names  by  periods  by  IEW. 

4.5.4  Enterprise  model  functions 

When  adding  function  names  to  IEW  models,  the  format  shall  be  as 
specified  in  4. 3. 3. 2  and  4. 3. 3. 2. 8.  Approved  abbreviations  shall  be 
used,  however  the  words  need  not  be  separated  by  hyphens.  Each  function 
shall  contain  the  correct  function  hierarchy/sequence  identifier  as  a 
prefix,  as  shown  in  the  following  examples: 

A  -  ACQUISITION  (Function) 

AA  -  PURCHASE  REQUEST  PROCESSING  (Subfunction  within  A) 

AB  -  OFFER  EVALUATION  (Subfunction  within  A) 

4.5.5  Enterprise  model  processes 

When  adding  process  names  to  IEW  models,  the  format  shall  be  as 
specified  in  4. 3. 3. 2  and  4. 3. 3. 2. 9  and  as  follows.  Approved 
abbreviations  shall  be  used,  however  the  words  need  not  be  separated  by 
hyphens.  Each  process  shall  contain  the  correct  process 
hierarchy/sequence  identifier  as  a  prefix,  as  shown  in  the  following 
example: 
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AB  -  OFFER  EVALN  (Function) 

ABA  -  CNDCT  INTL  EVALN  OFFER  (Process  within  Function  AB) 

ABAA  -  DTRMN  RSPVS  (Descendent  Process  within  Process  ABA) 

ABAB  -  EVAL  EXCPT  PROPL  (Descendent  Process  within  Process  ABA) 
ABB  -  CNDCT  PAS  (Descendent  Process  within  Process  AB) 

5.  CLASS  WORDS 

The  following  is  a  list  of  class  words  and  their  definitions  developed 
for  use  in  DLA.  The  class  words  shall  be  added  at  the  end  of  attribute 
names  (see  4. 3. 3. 2)  in  order  to  identify  the  type  or  domain  of  the  data 
named  by  the  attribute  name.  This  list  is  complete  for  the  Contractor 
Profile  Pilot  Project  but  may  be  amended  as  needed.  Approved 
abbreviations  are  provided  in  parentheses  following  the  class  word. 

AMOUNT  (AMT),  def:  Monetary  value  arrived  at  by  counting. 

CODE  (CD),  def:  Assigned  set  of  letters  or  numbers  used  to  represent 
words,  phrases,  or  objects. 

DATE  (DATE),  def:  Calendar  date,  commonly  expressed  by  day,  month,  and 
year. 

IDENTIFIER  (IDNTF),  def:  Sequence  of  alphanumeric  characters  that 
serves  to  indicate  some  object. 

INDICATOR  (INDCT),  def:  Word  that  indicates  a  certain  status,  as  in  a 
flag  indicating  that  only  one  of  two  mutually  exclusive  options 
may  be  true  at  one  time. 

NAME  (NAME),  def:  Designation  for  an  object  expressed  in  a  word  or 
phrase. 

NUMBER  (NBR),  def:  Nonquantitative  number  associated  with  an  object  or 
that  may  be  used  to  uniquely  identify  an  object. 

PERCENT  (PCT),  def:  Used  to  indicate  that  the  amount  or  quantity  is  a 
percentage. 

QUANTITY  (QTY),  def:  Non-monetary  numeric  value  arrived  at  by 
counting. 

RATIO  (RATIO),  def:  Calculated  relation  in  degree  or  number  between 
two  similar  things. 

SIZE  (SIZE),  def:  Dimensions  or  magnitude  of  something. 

TEXT  (TEXT),  def:  Unformatted  character  string  descriptive  field. 

TIME  (TIME),  def:  Specific  point  in  the  day  expressed  either  in  hours, 
minutes,  and  seconds  or  within  the  2400-hour  clock. 

6.  PRIME  WORDS 
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The  following  list  of  prime  words  was  developed  from  the  Conceptual 
Information  Architecture  (CIA)  and  the  Logical  Information  Architecture 
(LIA).  The  prime  words  are  those  used  to  name  conceptual  entities  in 
the  CIA  and  logical  entities  in  the  LIA.  This  list  is  complete  for  the 
Contractor  Profile  Pilot  Project  but  may  be  amended  as  needed. 

Approved  abbreviations  are  provided  in  parentheses  following  the  prime 
word. 

Alert-Action  (ALRAC),  def:  An  alert  action  acts  as  a  flag  to 
government  agencies  to  identify  contractors  who  exhibit 
deficient  performance  conditions. 

Clause  (CLAUS),  def:  A  term  or  condition  used  in  contracts  or  both 
solicitations  and  contracts,  and  applying  after  a  contract 
award  or  both  before  and  after  award. 

Contract  (CONTR),  def:  A  mutually  binding  legal  instrument  obligating 
the  seller  to  furnish  the  supply,  service,  or  data  items  and 
the  buyer  to  pay  for  them. 

Corrective-Action-Request  (CAR),  def:  Request  to  contractors  to  take 
corrective  action  when  a  deficiency  is  identified. 

Customer  (CUST),  def:  Any  government  organization  (DLA  or  otherwise) 
authorized  to  requisition  items. 

Data-Item-Description  (DID),  def:  Standard  form  that  provides 

descriptive  information  for  a  single  data  item  to  be  provided 
in  accordance  with  a  contract. 

Deficiency  (DEFCN),  def:  Any  defect  or  nonconforming  condition  found 
in  a  functional  area  at  the  time  of  review/evaluation. 

Disclosure  (DISCL),  def:  A  third  party  legal  action  for  a 

revelation/f inding  of  problems  with  products/ items  or 
potentially  illegal  business  practices  of  a  contractor. 

Employee  (EMPL),  def:  A  government  person  with  assigned 

responsibilities  who  performs  specific  tasks  in  support  of 
government  mission  and  functions. 

Engineering-Change-Proposal  (ECP),  def:  A  proposed  change  to  a 
Technical  Data  Package. 

First-Article-Test  (FAT),  def:  A  test  and  evaluation  of  the  first 
article  for  conformance  with  specified  contract  requirements 
before  or  in  the  initial  stage  of  production. 

Fund-Account  (FUND-ACCT),  def:  Monies  appropriated  to  satisfy 
requirements  for  goods  or  services. 

Government-Agency  (GOVAG),  def:  An  organizational  unit  or  office  of 
the  United  States  Federal  Government  whose  structure  and 
mission  are  prescribed  by  an  official  competent  authority  and 
is  responsible  for  specific  functions. 
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Item  (ITEM),  def:  A  supply  or  service  that  has  been  or  will  be 
acquired  to  fulfill  a  government  requirement. 

Laboratory-Test  (LAB-TEST),  def:  A  formal  test  of  the  quality  of  an 
item  using  laboratory  techniques  and  equipment,  performed  by 
in-house,  commercial,  or  government  laboratories. 

Legal-Entity  (LENTY),  def:  A  person  or  group  of  persons,  a  corporation 
or  other  existence  recognized  by  law  as  having  rights  and 
duties. 

Line-Item  (LNITM),  def:  A  supply,  service,  or  data  identified  in  a 
contract,  solicitation,  or  purchase  request  by  a  number. 

Offer  (OFFER),  def:  An  unsolicited  proposal  or  a  response  to  a 

solicitation  that,  if  accepted,  would  bind  the  offeror  to  the 
resultant  contract. 

Organization  (ORG),  def:  A  DLA  element  whose  structure  is  prescribed 
by  a  competent  authority  and  is  responsible  for  specific 
functions. 

Packaging  (PKGNG),  def:  Preservation,  packing  and  marking  of  products 
for  shipping,  stowage,  and  storage. 

Performance  (PRFMC),  def:  A  given  contractor's  effectiveness  and 
efficiency  to  satisfy  contractual  obligations. 

Preaward-Survey  (PAS),  def:  Survey  of  offerors  on  a  bid  performed 

prior  to  award  of  contract  to  assess  the  capability  of  a  bidder 
to  fulfill  contract  requirements. 

Product  (PROD),  def:  Anything  produced  by  human  or  mechanical  effort 
or  by  natural  processes. 

Production  (PRODC),  def:  The  conversion  of  raw  materials  into  products 
and/or  components  thereof  through  a  series  of  manufacturing 
processes. 

Purchase-Request  (PR),  def:  A  document  that  describes  the  requirements 
for  supplies  or  services  to  be  procured.  The  purchase  request 
provides  the  authority  for  procurement  and  initiates  the 
solicitation. 

Quality-Assurance  (QA),  def:  Management  of  activities  through  which 
the  government  achieves  the  quality  of  a  product  or  user 
satisfaction;  the  assurance  that  the  quality  characteristics  of 
products,  materials,  and  processes  are  controlled  through  the 
activities  of  product  audits,  inspection  and  testing, 
development  of  adequate  contract  and  specification 
requirements,  and  reviews. 

Safety  (SFTY),  def:  Prevention  or  protection  against  injury  or  loss. 
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Solicitation  (SOLCN),  def:  An  Invitation  for  Bid  (IFB),  Request  for 
Proposal  (RFP),  or  Request  for  Quote  (RFQ)  that  contains  the 
necessary  information  to  enable  prospective  contractors  to 
prepare  a  bid,  proposal,  or  quotation  in  a  responsive  manner. 

Statement-of-Work  (SOW),  def:  A  description  of  the  essential  physical 
characteristics  and  functions  required  to  meet  the  government's 
minimum  needs. 

Technical  (TECH),  def:  Specialized  or  unusual  practical  capability, 
especially  of  mechanical  or  scientific  subjects. 

Transportation  (TRNSP),  def:  Movement  or  shipment  of  materials, 
products,  and  passengers. 

Waivers-Deviations  (WAIVR-DEVTN) ,  def:  Written  authorizations  to 

depart  from  specified  requirements  or  to  accept  a  manufactured 
item  that  departs  from  specified  requirements. 
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APPENDIX  F 


CONFIGURATION  MANAGEMENT  DISCUSSION  FOR  CONTRACTOR  PROFILE  SYSTEM 
CONCEPTS 

o  ARCHITECTURES  AND  DOCUMENTS  ARE  COMPRISED  OF  MANY 
INDIVIDUAL  CONFIGURATION  ITEMS  WHICH: 

oo  ARE  PROOUCED  BY  DIFFERENT  TOOLS 

oo  MAY  BE  COMPONENTS  OF  MORE  THAN  ONE  ARCHITECTURE  AND 

/  OR  DOCUMENT 

oo  ARE  ANALYZED,  DESIGNED,  DEVELOPED,  AND  /  OR 
MAINTAINED  BY  DIFFERENT  INDIVIDUALS 

oo  MAY  RESIDE  IN  DIFFERENT  PHYSICAL  LOCATIONS 

oo  NEED  TO  BE  KEPT  IN  LOGICAL  'SYNCH'  WITH  EACH  OTHER 


A  CONFIGURATION  MANAGEMENT  APPROACH  IS  REQUIRED  WHICH  PROVIDES 

o  LOGICAL  ASSOCIATION  OF  ARCHITECTURES  AND  DOCUMENTS  WITH 
THEIR  RESPECTIVE  COMPONENTS  (CONFIGURATION  ITEMS) 

o  PROGRESSIVE  VERSION  CONTROL 

o  STATUS  AND  TRACKING  INFORMATION 

o  ASSISTANCE  IN  IDENTIFYING  POSSIBLE  PROBLEMS  AND  CRITICAL 
PATH  ITEMS 


INFORMATION  REQUIRED  TO  SUPPORT  A  CONFIGURATION  MANAGEMENT  APPROACH 

WHICH  ADDRESSES  THE  ABOVE  INCLUDES,  BUT  IS  NOT  LIMITED  TO 

o  NAME  (INDEX)  NAME  OF  CONFIGURATION  ITEM 

o  DESCRIPTION  DESCRIPTION  OF  CONFIGURATION  ITEM 

o  TYPE  (TBD)  ARCH  (ARCHITECTURE);  DOC  (DOCUMENT); 

ETF  (ENABLE  TEXT  FILE);  IEWP  (IEW 
PRODUCT);  PCDP  (PC  DICTIONARY  PRODUCT); 

HGP  (HARVARD  GRAPHICS  PRODUCT) 

o  TOOL  ENABLE,  IEW,  PCD,  HG) 

o  LEAD  PERSON  INDIVIDUAL  CHARGED  WITH  PRIMARY 

RESPONSIBILITY  FOR  GIVEN  CONFIGURATION 
ITEM 
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o  FACILITATOR  INDIVIDUAL  CHARGED  WITH  RESPONSIBILITY 
PROVIDE  TRAINING  IN  GIVEN  CONFIGURATION 
ITEM 


o  START  DATE 


o  DUE  DATE 

o  PCT  DONE  AS  REPORTED  BY  LEAD  PERSON 

o  LAST  REP  DATE  OF  MOST  RECENT  STATUS  REPORT  BY 

DATE  LEAD  PERSON 


o  PHYSICAL 
LOCATION 


FOR  EXAMPLE,  FILE  NAME  AND  MACHINE  ON 
WHICH  CONFIGURATION  ITEM  RESIDES 


o  SET  OF  CONTEXTUAL  INDICES,  EACH  OF  WHICH  INDICATES 
THAT  THE  GIVEN  CONFIGURATION  ITEM  IS  A  COMPONENT  OF 
A  PARTICULAR  DOCUMENT,  ARCHITECTURE,  UNIT,  ETC. 
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